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11 
PREFACE 


The  "Structure  and  Design  Philosophy  of  OL/2"  is  a  descrip- 
tion of  the  research  on  the  design,  implementation,  and  use  of 
the  OL/2  array  language.   Part  I,  which  is  contained  in  this  re- 
port, is  concerned  with  an  overview  of  a  subset  of  the  language, 
its  structure,  and  its  use.   Part  II,  on  the  other  hand,  is  con- 
cerned with  the  information  structures  for  dynamic  partitioning 
and  has  appeared  earlier  [8,  9J .   Further  documents  will  appear 
in  the  future  and  will  be  concerned  with  applications  of  OL/2,  a 
formal  description  of  the  syntax  and  semantics,  the  compiler, 
and  the  documentation  of  the  system.   Further  research  on  array 
languages,  compilation,  and  algorithms  is  continuing  as  an  out- 
growth of  this  work. 

The  OL/2  language  is  based  upon  two  very  fundamental  notions: 
the  first  is  that  a  computer  language  should  provide  a  nautral  and 
easy  means  of  communication  with  a  computer,  and  the  second  is 
that,  as  an  array  language,  it  should  contain  structures  that  per- 
mit one  to  exhibit  the  parallelism  that  is  inherent  in  algorithms. 

To  achieve  the  first  goal,  a  syntax  and  a  set  of  array  oper- 
ations was  chosen  to  conform  rather  closely  to  the  structure  of 
the  natural  language  of  mathematics.   As  a  result,  some  rather 
sophisticated  array  algorithms  may  be  constructed  using  relatively 
few  statements,  say  m  10  or  20,  compared  to  5  or  10  times  this 
number  for  nonarray  languages.   This  has  a  direct  bearing  upon 
the  time  required  to  investigate  a  new  algorithm.   In  particular, 
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both  programming  time  and  programming  detail  are  reduced  by  th< 
high  level  nature  of  the  language.   For  instance,  I  have  ob- 
served that  students  may  spend  a  day  or  more  trying  to  understand 
a  new  mathematical  problem  which  may  require  only  10  OL/2  state- 
ments for  its  algorithmic  representation.   This  observation  merely 
underscores  the  fact  that  most  of  the  difficulty  resides  in  under- 
standing the  underlying  concepts  and  mathematical  foundations  of 
the  algorithm,  and  not  in  programming.   For  this  reason,  OL/2 
should  prove  to  be  a  very  useful  pedagogical  and  research  tool. 
In  effect,  the  language  establishes  a  closer  relationship  between 
the  user,  his  algorithm,  and  the  computer. 

The  second  fundamental  aspect  of  the  language  is  concerned 
with  array  processing  and  the  construction  of  array  algorithms 
for  parallel  processing.   It  is  my  belief  that  an  array  language 
which  allows  for  the  construction  of  algorithms  that  exhibit  the 
parallelism  that  is  inherent  in  those  algorithms  is  essential  to 
understanding  parallel  processing.   The  OL/2  language  contains 
several  new  language  constructs  which  allow  the  user  to  exhibit 
[implicitly)  this  parallelism.   However,  in  many  cases,  the  user 
is  forced  to  reorganize  his  thoughts  on  how  to  construct  algor- 
ithms.  In  time,  and  with  sufficient  experience,  one  begins  to 
understand  what  is  meant  by  an  "array  algorithm."   The  transi- 
tion from  a  sequential  to  an  array  algorithm  is  not  always  easy, 
but  once  the  transition  is  accomplished  it  is  almost  always  en- 
lightening!  In  my  opinion,  a  thorough  understanding  of  array 
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algorithms  will  provide  vital  insight  into  the  problems  of  the 
design  and  development  of  array  computers  and  array  compilers 
of  the  future. 

The  above  comments  have  been  concerned  with  the  objectives 
of  the  OL/2  language,  with  its  use,  and  with  its  implications. 
The  present  report,  however,  is  concerned  with  an  overview  of 
the  language- -particularly  from  a  structural  point  of  view.   In 
separate  chapters,  we  discuss  the  algebraic  structure,  geometric 
structure,  program  structure,  and  dynamic  partitioning  in  the 
language.   With  respect  to  algebraic  structure,  it  is  a  common 
misconception  that  array  languages  are  concerned  only  with  matrix 
operations.   In  order  to  expand  one's  viewpoint,  I  encourage  the 
reader  to  substitute  another  algebraic  structure  for  the  one  pre- 
sented In  Chapter  1.  There  is  nothing  special  about  the  algebraic 
structure  there  except  that  it  is  very  rich  in  mathematical  and 
algorithmic  content.   Similarly,  one  may  alter  or  augment  the 
geometric  structure  of  Chapter  2  with  the  same  or  a  different 
algebraic  structure.   This  procedure  will  also  be  valuable  in 
illuminating  the  structural  independencies  within  the  language. 

There  are  many  examples  within  this  report  which  illustrate 
various  types  of  statements  and  features  of  the  language.   For 
many,  like  the  numerical  analysts  with  algorithmic  insight,  the 
transition  from  these  examples  to  real  algorithms  will  be  rea- 
sonably apparent,  but  for  others  It  may  be  difficult  to  capture 
the  essence  of  the  language  and  the  usefulness  of  certain  fea- 
tures without  this  algorithmic  knowledge.   In  the  future,  a 
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separate  document  on  array  algorithms  should  help  to  alleviate 
part  of  this  problem,  but  the  relationship  between  the  language 
and  the  (infinite)  classes  of  algorithms  for  which  it  is  in- 
tended- -is  more  intimate  than  with  most  languages.   Knowing 
about  arrays  is  different  than  knowing  how  arrays  are  used  as 
mathematical  operators.   An  array  as  a  mathematical  operator 
with  its  algebraic  (and  geometric)  structure  is  a  more  abstract 
object  than  a  real  or  complex  number.   This  is  why  an  array 
language  is  different  from  a  non-array  (element  language)  lan- 
guage--the  abstract  objects  we  use  to  communicate  with  are  at 
different  levels . 
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CHAPTER  1 
ALGEBRAIC  STRUCTURE 

In  this  chapter  we  introduce  some  primitive  array  operations 
which  are  associated  with  the  algebraic  structure  of  the  language; 
other  array  operations  which  are  independent  of  this  structure 
are  discussed  in  a  separate  chapter.   Our  purpose  is  to  introduce 
only  the  simplest  aspects  of  the  language  so  that  we  can  identify 
some  of  the  problems  that  arise  in  the  design  and  implementation 
of  array  languages. 

1  .  1.   Scalar  Operations 

Scalars  are  real  or  complex  numbers.   In  the  implementation, 
however,  scalars  arc  represented  in  the  usual  way  with  floating- 
point or  fixed-point  numbers.   It  should  be  kept  in  mind,  however, 
that  other  representations  and  modes  of  arithmetic  are  envisioned 
such  as  rational  arithmetic,  multiple  precision  arithmetic,  and  a 
form  of  significant  digit  arithmetic. 

Wherever  a  scalar  is  used  in  OL/2,  one  may  substitute  an 
arbitrary  arithmetic  expression;  for  instance,  in  this  implementa- 
tion any  PL/1  arithmetic  expression  could  be  inserted  in  place  of 
the  scalar.   Therefore,  scalar    should  be  interpreted  to  mean  a 
single  scalar  valued  variable  or  constant,  or  any  expression  or 
function  which  upon  evaluation  results  in  a  scalar. 


VECTOR_PRIMITIVES:       MAIN    PROCEDURE; 

N    =    4; 

LET  x,  y,  AND  z  BE  VECTORS  OF  ORDER  (N);   LET  s 
AND  t  BE  SCALARS;   INPUT  x,  y;   OUTPUT  x,  y; 

VECTOR_ADDITION :   VECTOR_SUBTRACTION : 

z  =  x  +  y;  OUTPUT  z; 

z    =  x   -  y;    -,  OUTPUT  z; 

MU LT I P L I C AT I 0 N_B Y_S C AL AR : 

z  =  3, 14xy;  OUTPUT  z; 

VECTOR_NORM: 

t  =  ||  x  ||;  OUTPUT  t; 

INNER_PRODUCT:   VECTOR_TRANSPOSE : 

s  =  (x,y);  OUTPUT  s; 

t  =  x'xy;  OUTPUT  t;  . 

END  VECTOR  PRIMITIVES; 


FIG.  1.2.1   The  primitive  vector  operations  are  illustra- 
ted above.   All  of  the  examples  in  this  paper  were  construc- 
ted at  a  computer  terminal  using  an  86  character  set  which 
differs  only  slightly  from  the  standard  60  character  set. 
If  there  is  sufficient  space,  we  will  display  the  output 
(or  part  of  it)  as  it  is  printed  at  the  terminal. 


3 
1.2   Primitive  Vector  Operations 

In  mathematics,  a  vector  is  usually  defined  without  any 
reference  to  whether  it  is  a  "row  vector"  or  a  "column  vector." 
Similarly,  a  computer  language  requires  no  explicit  specification 
but  input  and  output  conventions  demand  some  convenient  format  for 
display.   Therefore,  to  be  specific,  we  state  that  all  vectors  in 
vector  declarations  are  to  be  interpreted  as  column  vectors.   In 
OL/2,  if  x  is  a  column  vector,  then  x'  (the  transpose  of  x)  denotes 
a  row  vector.   This  agrees  with  the  usual  mathematical  conventions. 

Some  primitive  vector  operations  in  OL/2  are  defined  in  Fig- 
ure 1.2.1.    In  these  definitions  there  is  no  indication  of  the 
type  of  arithmetic  that  is  used,  nor  is  the  type  of  vector  norm 
defined.   From  the  algebraic  point  of  view,  the  elements  of  x  and 
y  could  be  real  (floating-point),  or  complex,  or  rational,  or  inte- 
ger.  Our  convention  in  OL/2  is  to  assume  that  the  elements  are 
real  (floating-point)  numbers  unless  they  are  declared  otherwise. 
Similarly,  the  vector  norm  is  assumed  to  be  the  Euclidean  norm 
(sometimes  referred  to  as  the  l^    norm),  unless  a  different  vector 
norm  {I  ^    norm,  max-norm)  is  specified  in  a  LET  statement.   "De- 
faults" such  as  these  are  common  in  computer  languages,  and  we 
make  use  of  them  wherever  it.  seems  to  enhance  the  language. 

The  nature  and  extent  of  the  declarations  in  a  language  is 
often  a  point  of  much  concern.   At  one  extreme  we  find  languages 
with  few  if  any  declarations,  and  at  the  other  extreme  we  find 


The  definitions  and  examples  will  usually  be  presented  as 
simple  OL/2  programs.   This  will  introduce  the  reader  to  a  subset 
of  the  syntax.   We  make  no  pretense  of  defining  the  whole  language 
in  a  rigorous  manner;  this  will  be  the  subject  of  another  report. 


EXAMPLES:   MAIM  PROCEDURE; 

N  =  4; 

LET  x,  y,  AND  z  BE  VECTORS  OF  ORDER  (M);   LET  s 
AND  T  BE  SCALARS;   INPUT  x,  y;   OUTPUT  x,  y; 


VECTOR_EXPRESSIONS 
s  =||  x  -  y 
z  =  (  |  |  x  -  y 


I  x  +  y  ||; 

|  (x,y)  xy  -  x  I  I  )  ><x 


IF 


x  -  y 


>  0.0001  THEN  s  =  1.414; 


OUTPUT  s; 

y; 

OUTPUT  z' ; 
OUTPUT  s; 


z  =  x   +   (  y 

END  EXAMPLES; 


-  3*x  )  '  xyxx; 


OUTPUT  z ' ; 


IX*    *    *   ! 
-1- 

1  .000000E+00 
2.000000E+00 
3.000000E+00 
4.000000E+00 


I Y  *  *  *  I 
-1- 
5.000000E+00 
6.000000E+00 
7.000000E+00 
8.000000E+00 


is*    *   *   1 
2.654724E+01 


J2'   **.#•##**;*******     J 

-1-  -2-  -3-  -4- 

9.310577E+02    1.858115E+03    2.785173E+03    3.712231E+03 


IS*    *    *   i 
1 .414000E+00 


1  Z  '  *    *    *    *    *    *    *    *    *    *    *    *    *    *   I 
-1-  -2-  -3-  -4- 

-3.500000E+01   -7.000000E+01   -1 . 050000E+02   -1 . 400000E+02 

FIG.  1.2.2   Examples  of  vector  expressions.   The  output  shown  is 
the  default  format;  other  formats  are  discussed  in  the  user's 
guide. 
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languages  which  require  nearly  every  data  type  to  be  declared. 
There  are  many  logical  reasons,  as  well  as  many  prejudices,  that 
language  designers  use  to  justify  their  decision.   But,  in  general, 
the  decision  should  be  based  upon  the  users'  preferences  and  not 
the  designers'.   Whether  this  objective  will  be  met  in  OL/2  or  not 
can  only  be  determined  in  the  future  when  applications  oriented 
users  gain  some  experience  with  it. 

From  another  point  of  view,  we  feel  that  a  language  should 
aid  in  the  communication  of  algorithms  between  humans  as  well  as 
between  man  and  machine.   To  satisfy  these  goals,  we  have  tried 
to  adopt  a  flexible  syntax  that  is  natural  in  the  sense  that  it 
is  closer  to  English  in  style  and  structure.   Through  this  approach 
we  are  able  to  achieve  a  certain  degree  of  self -documentation  for 
communicating  algorithms  between  humans,  and  at  the  same  time  we 
find  that  it  is  relatively  easy  to  learn  because  it  follows  conven- 
tional notation. 

The  first  LET  statement  in  Figure  1.2.1  also  illustrates  how 
algebraic  structure  can  be  induced  into  a  language  through  the 
attribute  VECTOR.   By  allowing  different  attributes  we  can  allow 
different  algebraic  operations.   The  attributes,  therefore,  reflect 
not  only  the  type  of  data,  but  also  the  amount  of  algebraic  struc- 
ture in  the  language. 

The  syntax  of  Figure  1.2.1  is  not  rigid.   Abbreviations, 
alternative  forms,  and  options  are  included  to  make  the  language 
more  natural.   For  instance,  the  previous  declarations  may  be 
written  in  01./  2  as  shown  in  Figure  1.2.3. 


DECLARATIONS:   MAIN  PROCEDURE; 

N  =  4; 

LET  V  BE  A  REAL  FINITE  DIMENSIONAL  VECTOR  SPACE 
OF  DIMENSION  (N);  LET  x,  y,  AND  z  BE  ELEMENTS  OF  V; 
LET  s  AND  t  BE  SCALARS;   INPUT  x,,y;   OUTPUT  x,  y ; 


IF 


II  x  -  y 
(||  x  -  y 

I  x  --  y  | 


|   +   | |  x  +  y  | I ;  OUTPUT  s ; 

I   +   II  (x,y) xy  -  x  | | )xx   +   y; 

OUTPUT  z'  ; 
>  0.0001  THEN  s  =  1.414;       OUTPUT  s ; 


=  x   +   (  y  -  3><x  )'xyxx; 


OUTPUT  z1 


END  DECLARATIONS; 


FIG.  1.2.3   A  variation  on  the  declarations  of  Figure  1.2.2. 
This  example  illustrates  what  we  mean  by  a  "natural"  syntax, 
and  it  also  illustrates  how  the  program  is  "self -documenting' 
comments  are  allowed,  but  seldom  needed. 
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This  form  is  closer  to  the  mathematical  format  used  in  linear 
algebra  than  the  former.   It  also  has  been  made  more  precise  by 
the  use  of  the  attribute  REAL.   The  vectors  X,  Y,  and  Z  and  the 
scalars  are  interpreted  as  real  numbers.   Once  such  a  statement 
is  written  it  becomes  part  of  the  documentation  as  well  as  part 
of  the  program.   From  the  reader's  point  of  view  there  is  no  ambig 
uity  with  respect  to  interpretation  of  X,  Y,  and  Z  or  the  alge- 
braic operations  involving  X,  Y,  or  Z  because  the  properties  of 
a  real  vector  space  are  well  defined. 

The  previous  example  illustrates  how  the  syntax  may  vary 
within   certain  limits  to  achieve  a  more  natural  language.   The 
recognition  of  different  syntactic  forms  is  not  an  undue  burden 
for  a  compiler  and  probably  will  be  less  of  a  burden  in  the  future 

A  natural  and  flexible  syntax  is  also  practical  in  an  interactive 

2 
environment,   because  one  can  prompt  a  user  at  each  statement  with 

a  message  or  suggestion  when  he  makes  a  mistake.   This  seems  pref- 
erable to  emitting  a  long  list  of  error  messages  or  incorporating 
error  correcting  features.   In  the  future,  with  better  terminals 
and  better  communication  links  to  computers,  it  may  be  reasonable 
for  language  designers  to  provide  more  flexible  syntax  and  to 
provide  for  a  statement  by  statement  "prompter"  to  eliminate  the 
need  to  memorize  syntax. 

Another  aspect  of  flexible  syntax  involves  the  use  of  "user 
defined  languages"  through  extensible  languages.   The  objective 


2 
The  present  implementation  of  OL/2  is  not  interactive,  but 
an  interactive  syntax  analyzer  for  OL/2  was  constructed  on  another 
computer  (Burroughs  6500),  allowing  immediate  feedback  on  a  state- 
ment by  statement  basis  (see  Sanford  [12]). 


would  be  to  allow  languages  with  similar  (algebraic)  structure  to 
be  used  in  several  application  areas  which  tend  to  use  different 
terminology  but  basically  the  same  operations.   This  might  be  more 
practical  than  trying  to  develop  a  separate  language  for  each  area 
of  application.   There  are  difficulties  associated  with  extensible 
languages  [14],  but  progress  in  this  direction  seems  easier  because 
it  is  a  small  step  compared  to  some  of  the  attempted  goals  with 
extensible  languages  so  far. 

1  •  3   Primitive  Matrix  Operations 

The  primitive  matrix  operations  are  illustrated  in  Figure 
1.3.1.   It  is  evident  from  these  examples  that  the  operations  in- 
volving matrices,  vectors,  and  scalars  in  OL/2  agree  in  form  and 
spirit  with  the  usual  mathematical  notation.   A  few  mandatory 
symbols,  such  as  *  for  multiplication  might  still  bother  the  pur- 
ist or  anyone  who  is  unfamiliar  with  programming,  but  we  tend  to 
ignore  these  objections.   A  more  pertinent  question  might  concern 
itself  with  the  type  of  matrix  norm.   As  in  the  case  of  vectors, 
we  adopt  one  matrix  norm,  the  Schur,3  as  the  default,  and  provide 
a  means  for  declaring  other  matrix  norms  in  LET  statements.   The 
number  of  such  norms  is  limited  by  practical  considerations. 
For  instance,  it  is  difficult  to  provide  ||A||2,  the  spectral  norm, 
since  this  requires  finding  the  largest  eigenvalue  in  absolute  value 


In  OL/2  we  use  ||A||for  all  matrix  norms.   The  default  is  the 
Schur  matrix   norm  and  is  defined  as  CZI |ail | 2)1/2  but  is  denoted 
in  the  literature  by  ||A||E  (see  Wilkinson  |l3]  p.  81).   The  litera- 
ture is  also  inconsistent  in  the  use  of  the  word  "Euclidean  matrix 
norm   (sec,  lor  example,  Isaacson  and  Keller  |4  1,  n.  12  and  Wilkin- 
son above)  . 


MATRIX_PRIMITIVES:   MAIN  PROCEDURE; 

II  =  H; 

LET  A,    B,    AND    C   BE   MATRICES    OF   ORDER    (N);       LET   x,    y, 

AND   z    BE    VECTORS    OF  ORDER    (II);      LET   p    AMD   q  BE    SCALARS ; 

LET    I    BE   THE    IDENTITY   MATRIX   OF   ORDER    (N);  INPUT   A,    B,    z; 

MATRIX_ADDITION:  C    =    A   +    B;  OUTPUT    C,    A,    B; 

HULTIPLICATI0NJ37_SCALAR:  C    =    3.14*A;  OUTPUT    C; 

MATRIXJIULTIPLICATION:  G    =    A*B;  OUTPUT    C,    A,    B; 

MATRIXJIORM:  q    =     II    A    I  I;  OUTPUT    q; 

MATRIX_TIMES__VECTOR:  y   =    A*z;  OUTPUT   y'; 

VECTOR_TRANSPOSE:  y    =    Cz'xA)1;  OUTPUT   y!; 

MATRIX_TxRANSPOSE:  x   =    A'*z;  OUTPUT   x' ; 

MATRIX_IDENTITI7:         ,        .  C=A+I;  OUTPUT    C; 

END   MATRIX   PRIMITIVES; 


FIG.     1.3.1      Examples    illustrating    some   of   the    primitive 
matrix    operations. 
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of  A  A  where  A   is  the  Hermitian  transpose  of  A.   Other  matrix 
norms  such  as  || A j | ^  (maximum  absolute  column  sum)  and  ||A|| 
(maximum  absolute  row  sum  J  are  easy  to  implement  and  are  included 
as  options  for  the  user. 

The  matrix  transpose  and  vector  transpose  are  clearly  defined 
mathematical  operations.   The  language  does  not  indicate  how  this 
operation   is  implemented,  but  the  implementation  is  important 
to  the  user,  since  it  involves  economics. 

Consider,  for  example,  the  transpose  of  a  large  matrix  A, 
which  is  written  in  01/2  as  A'.   in  many  languages  and  in  many 
users'  programs  storage  for  A  is  duplicated  in  order  to  form  A'. 
This  is  expensive  to  the  user  in  both  space  and  time.   It  is 
better  to  build  control  structures  which  recognize  A'  without 
duplicating  storage  and  "operate"  with  either  A  or  A'  with  equal 
case.   This  is  the  approach  we  have  adopted  in  0L/2  for  both  the 
vector  and  matrix  transpose;  it  applies  not  only  to  individual 
arrays,  but  also  to  array  expressions  which  arc  discussed  in 
Section  1.4. 

Figure  1.3.1  also  introduces  the  Identity  matrix.   Again 
there  is  no  reference  to  how  it  is  represented  internally.   The 
implementation,  however,  uses  the  properties  of  the  identity 
matrix  to  reduce  both  storage  and  time  during  execution.   Effec- 
tively, the  declaration  constrains   I  to  be  a  constant  matrix  and 
imbues  it  with  both  algebraic  and  "geometric"  properties.   In 
Chapter  2  we  will  extend  this  idea  to  other  data  types. 
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EXAMPLES:   I  IAIN  PROCEDURE; 

N  =  4; 

LET  A  AND  B  BE  MATRICES  OF  ORDER  (N);   LET  x,  y, 
z,  AND  r  BE  VECTORS  OF  ORDER  (N);   LET  p  AND  q  BE  SCALARS; 
INPUT  x,  y,  z,  A,  B;   OUTPUT  x,  y,  z.|A,  B; 

p  =  3  .  1  4  ;  q  =  2  .  7 1  ; 

S I  i  IP  LE_ARRA7_E  XP  RE  S  S 1 0  N S  : 

r  =  z  -  Axy;  OUTPUT  r1 ; 

y  =  y  -  (r,r)/(Axr,r)xr;  OUTPUT  y*; 


z  =  ((  A'xx  +  y!xBxXxy  ) ' *A  ) ' ;     OUTPUT  z'; 

y  =  3xSIN(  | |A| |  -  | |B| I  )xAxX   +   2x(x  +  y); 

OUTPUT  y' ; 
IF  | |  A  r  B  II  >  0.013  THEN  q  =  1.2;   ELSE  p  =2.3; 

OUTPUT  q,  p; 


END  EXAMPLES; 


iX    ! 

IY    ! 

iZ    I 

-1- 

-1- 

-1- 

1-         1 

-1-         5 

-1-         9 

2-         2 

-2-         6 

-2-       10 

3-         3 

-3-         7 

-3-       11 

-4-    4      -4-    8      -4-   12 


!A  *    *    *    i  IB  *  *  *  1 

'_-!_  -2-  -3-  -4-  -1-  -2-  -3-  -4- 

-1-   13   14   15   16  -1-  •  29  30  31  32 

-2-   17   18   19   20  -2-   33  34  35  36 

-3-   21   22   23   24  -3-   37  38  39  40 

-4-   25   26   27   28  -4-   41  42  43  44 


(Continued  on  p.  13) 

FIG.  1.3.2   Simple  array  expressions  using  the  operations  of 
linear  algebra. 
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1 • 4   Simple  Array  Expressions 

The  primitive  vector  and  matrix  operations  may  be  used  to 
form  (array)  expressions.   The  only  restriction,  from  the  point  of 
view  of  the  language,  is  that  the  vectors,  matrices,  and  scalars 
be  combined  according  to  the  usual  rules  of  linear  algebra.   We 
refer  to  such  array  expressions  as  "simple"  because  they  involve 
only  simple  data  types.   By  including  other  data  types  and  imbed- 
ding additional  algebraic  structure  into  the  language  we  can  intro- 
duce more  complicated  types  of  array  expressions.   it  will  become 
evident  that  the  problems  of  implementation  also  become  more 
difficult. 

Simple  array  expressions  are  easy  to  write  in  01, /2,  but  they 
are  not  simple  to  implement.   Consider,  for  example,  the  array 
expression  A*B  where  A  and  B  are  matrices.   There  is  absolutely  no 
problem  as  long  as  A  and  B  arc  of  reasonable  order.   But  users 
tend  to  use  matrices  that  are  unreasonably  large  (though  reasonable 
to  them)  and  they  write  not  only  A<B  but  BxA,  sometimes  in  the  same 
statement.   It  is  easy,  with  an  array  language,  to  write  array 
expressions  which  demand  large  storage  facilities  and  challenging 
computational  facilities.   It  is  evident  that  the  traditional  com- 
puter architecture  and  current  paging  methods  arc  not  adequate  for 
many  large  array  problems.   To  solve  some  of  these  problems  it  may 
be  reasonable  to  utilize  some  of  the  algebraic  structure  to  develop 
special  control  structures  to  handle  the  special  paging  methods 
associated  with  efficient  array  expression  evaluation.   The  large 
number  of  array  problems  could  easily  justify  a  special  approach. 
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M,   I  **************       I 
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-1-        -3.730000E+02  -4. 760000E+Q2  -5. 790000E+02   -6 . 820000E+02 

,Y  ***************    x- 

-!-  -2-  -3-             -4- 

_-!_         y.4978lOE+00  1.173983E+01  1  .  398.1  86E+01    1.622388E+01 

,  7  i  *    *    *  *         *         *         *  *         *         *         *         *         *         *  1 

'  "     -«,-  -2-  -3-             -4- 

_-!_         1.993352E+07  2.093667E+07  2.193981E+07    2.294295E+07 

,Y  •  *    *    *  *    *    *    *  *    *    *    *   .  *    *    *  ! 

-    .-,_  -2-  -3-             -4- 

-1-        -1.Q35022E+Q2  -1 . 3021 75E+02  -1 . 569329E+02   -1  .  836482E+02 

io   *    *    *  i  1P_  *    *    *  ! 

-1.200000E+00  3.140000E+00 


FIG.  1.3.2   Simple  array  expressions  using  the  operations  of 
linear  algebra.   (Continued) 
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Unfortunately,  a  solution  to  this  problem  is  not  known,  at  least 
within  the  context  of  the  various  data  types  we  shall  introduce  in 
OL/2.   However,  we  can  mention  some  possible  conditions  which 
should  be  considered. 

The  first  is  primarily  a  language  observation.   In  any  array 
expression,  we  usually  have  several  algebraically  equivalent  methods 
of  evaluating  the  expression.   Consider,  for  example,  the  expres- 
sions of  Figure  1.4.1. 


LET  A,  B,  AND  C  BE  MATRICES  OF  ORDER  (II);   LET  x,  y, 

AMD  z  BE  VECTORS  OT  ORDER  (II);   INPUT  A,  B,  x,  y,  z; 

z  =  A*Bxy  _  2*(z  +  x); 
x  =  zxy'xz  +  (A*z,y)*y; 


Figure  1.4.1 

It  is  clear,  from  an  algebraic  point  of  view,  that  the  expres- 
sion AxBxy  may  be  evaluated  as  (A*B)xy,  or  as  A<(B*y).   The  lat- 
ter clearly  requires  the  fewest  number  of  operations  (2n2  versus 

3     2 
n   +  n   multiplications).  A  similar  situation  occurs  in  evaluat- 
ing the  second  expression  as  (z*y')*z  or  as  z*(y'xZ).  Therefore, 
It  is  natural  to  define  a  set  of  precedence  rules  for  the  language 
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which  minimizes  the  number  of  operations  when  evaluating  an  array 
expression.   This  becomes  especially  important  for  array  expres- 
sions which  contain  large  arrays. 

Storage  is  also  a  problem  in  evaluating  an  array  expression; 
for  example,  consider  the  expression  zxy'xz.   if  We  evaluate  this 
expression  as  (zxy')xz,  then  we  must  increase  the  amount  of  storage 
so  as  to  hold  the  partial  result  z*y'  which  is  a  matrix;  however, 
if  we  evaluate  the  expression  as  zx(y'xz),  then  we  need  storage  for 
only  y'xz,  which  is  a  scalar.   The  difference  between  these  two 
alternatives  is  dramatic  for  large  n,  not  only  in  terms  of  storage 
but  also  in  terms  of  the  number  of  operations. 

The  obvious  problem,  then,  is  to  minimize  the  number  of  opera- 
tions and  the  amount  of  temporary  storage  simultaneously  for  arbi- 
trary array  expressions.   Unfortunately,  this  problem  cannot  be 
solved,  in  general. 

The  choice  we  made  was  to  minimize  the  number  of  operations 
even  if  it  requires  additional  storage  for  temporary  results.  The 
justification  for  this  approach  is  based  upon  the  fact  that  memory 
capacity  is  increasing  rapidly  and  hardware  techniques  will  aid  in 
removing  the  disparity  between  memory  hierarchies.  The  precedence 
rules  of  Figure  1.4.2  arc  the  result  of  this  decision. 

One  should  realize  that  the  precedence  rules  do  not  guarantee 
that  the  minimum  number  of  operations  will  be  achieved  when  eval- 
uating array  expressions.   For  example,  consider  the  expression 
AxB*(;  where  A,  R,  and  C  are  rectangular  arrays  which  are  dynamic. 
In  this  case  precedence  (based  on  minimum  operations)  depends  upon 
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SYMBOLS 

s:   scalar,  x,y:   vectors,  A,B:   matrices 
UNARY  OPERATIONS      {';  +,  -)     (Precedence  =  1) 
Transpose         Unary  +  Unary 

x1  +x  "x 

A-  +A  "A 

FUNCTIONAL  OPERATIONS   {(  ,  )  ,  I  I   II >   (Precedence  =  2) 
Inner  Product  Forms       Norms 
(x,y)  I M I 

x'xy  ||A|| 

SCALAR  OPERATIONS   {x ,  /,  +  ,  -,  ♦  ,  fh}    (Precedence  =  3) 
Each  scalar  expression  is  evaluated  using  the  normal 
scalar  precedence  (£n  denotes  a  scalar  function). 

ARRAY  OPERATIONS    {  +  ,  -',"x.  /»   H,    0'    ffl'   F  (  ^} 
Matrix-vector     (Precedence  =  4) 

Axx  ,  x ' xA 
Matrix  multiplication   (Precedence  =  5) 

AxB 

Multiplication  by  scalar  (or  division)  (Precedence  =  6) 
sx/v    ,    Axs    ,    sxx    ,    xx  s 
A/s  x/s  s^O 

Addition  and  element  operations   (Precedence  =  7) 

A+B         ,         A-B         ,         A  S  B         ,         A   0   B         ,        A   ffl  m      ,    F| 
x+y        ,        x-y        ,        x  E  y        ,        x.  0-y        ,        x  ffl  .m    .  ,    F| 

Outer  Product*   (Precedence  =  8) 


t 


xxy 

Assignment    (Precedence  =  9) 
s=s    ,    x=y 


A=B 


FIG   14.2    Precedence  rules  for  algebraic  operations  in  0L/2' 
The "lowest  precedence  is  performed  first;  equal  precedence  implie 
left  to  right  evaluation.   The  operations  g.  0,  EU  and  F (  J  are 
defined  in  section  2.7. 

*The  outer  product  has  precedence  =  5  in  version  3  of  the  OL/2 
compiler;  also  some  higher  dimensional  array  operations  fall  into 
the  precedence  =  8  category. 


the  values  of  the  bounds  for  each  dimension  and  these  are  not  avail- 
able until  run-time.   It  is  even  possible  to  execute  the  same  array 
expression  several  times  within  a  program  with  different  values 
for  the  bounds,  which  would  force  the  evaluation  into  (A*B)xC  one 
time  and  A*(BxC)  another  to  achieve  the  minimum  number  of  operations. 
Thus,  it  is  impractical  to  try  to  achieve  this  goal  in  all  cases. 
in  Chapter  3  we  introduce  an  alternative  which  will  eliminate  this 
problem  for  many  practical  algorithms. 

Dynamic  arrays  in  simple  array  expressions  illustrate  one 
problem  which  the  array  language  designer  must  face.   As  we  shall 
see  in  later  sections,  0../2  contains  additional  data  types  which 
servo  to  compound  this  problem.   It  will  also  become  evident  in 
later  sections  that  dynamic  arrays  in  array  expressions  are  consid- 
ered as  normal  and  static  arrays  as  exceptional.   These  dynamic 
arrays  do  not  change  just  upon  block  entry,  but  rather  every  time 
the  array  statement  is  executed.   This  is  „  fact  wMch  emcrges 
from  studying  array  algorithms.   Wc  discuss  the  control  structures 
for  dynamic  arrays  in  OL/2  in  a  separate  report  |8,  9]. 

There  is  another  approach  to  array  evaluation.   Instead  of 
evaluating  the  array  expression  A*B*y  by  evaluating  first  B*y, 
then  multiplying  this  result  on  the  left  by  A,  we  could  complete 
part  of  the  operation  of  B*y,  say  y  times  the  first  row  of  B,  and 
then  use  this  partial  result  on  the  first  column  of  A~co.pl.tinj 
-rt  of  the  next  operation  of  A  times  Bxy.   This  represents  array 
Valuation  across  the  expression  and  is  quite  different  from  former 
techniques.   For  arbitrary  array  expressions  this  is  a  difficult 


problem,  especially  if  the  arrays  are  large  and  all  ef  the  array 
operands  cannot  reside  in  core  memory.   Thus,  we  reject  this 
approach  which  would  reduce  temporary  storage  at  the  expense  of 
more  complicated  array  control  structures. 

In  this  section  we  have  mentioned  several  problems  associated 
with  evaluating  simple  array  expressions.  As  additional  algebraic 
structure  ls  imbedded  into  the  array  language,  as  data  types 


become  more  numerous,  or  j 


as  computer  architecture  changes --the 


array  evaluation  problem  becomes  even 


more  difficult.   Large  arrays 


present  a  particularly  difficult  problem  in  view  of  the  many  types 
of  operands  that  are  allowed  and  the  fact  that  they  arc  normally 
dynamic.   It  appears  that  there  are  many  problems  to  be  solved  and 
the  need  for  good  algorithms  is  apparent.   Probably  the  general 
paging  techniques  will  not  be  satisfactory  since  they  do  not  take 
into  account  the  algebraic  structure  and  special  information  that 
is  associated  with  array  expressions. 

1  ■  5   fixpl  ici  t  Sequences 

Sequences  of  mathematical  objects  are  fundamental  to  under- 
standing much  of  mathemat.es,  but  they  are  also  the  basis  of  many 
computer  algorithms  as  well.   Computer  languages,  however,  do  not 
contain  sequences  as  such,  but  require  their  construction  in  an 
artificial  (memory  dependent)  way.   For  array  languages,  this  arti- 
ficiality should  be  removed;  sequences  should  bo  made  explicit. 
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As  an  example,   consider  the  mathematical  problem  of  solving 
a  system  of  equations 

Au  =  v 


where  A  is  assumed  to  be  a  nonsingular  matrix  of  order  n;  u  and  v 
are  vectors  each  having  n  components.   Mathematically  we  can  solve 
this  system,  under  appropriate  conditions,  by  choosing  an  initial 
approximation  z(0)and  computing  the  sequence 

z(k+1>=B^+w     fork  -0,1,...   .  (1.5) 

where  B  =  I-sA,  w  =  sv,  and  s  is  a  specified  constant.   Since  this 
algorithm  is  merely  a  form  of  successive  approximations,  we  know 
that  the  sequence  of  vectors  {  z^  under  appropriate  conditions,  con- 
verges to  the  solution  u.   Even  though  this  algorithm  is  not  prac- 
tical, it  still  illustrates  how  sequences  can  be  used  in  OL/2. 
More  practical  algorithms  will  be  presented  later. 

The  usual  programming  technique  is  to  let  some  (vector)  vari- 
able x  represent  the  old  value  z00  and  some  other  (vector)  variable 
X  hold  the  new  value  z(k+1)  so  that  the  algorithm  may  be  terminated 
when  ||x-y||  is  sufficiently  small.   Therefore,  equation  (1.5) 
would  be  written  as : 

x  =  y 

y  =  Bxy  -  vv 

On  each  iteration  we  copy  the  value  of  y  into  x.   For  large  n  this 
technique  is  not  recommended.   It  is  more  efficient  and  more  nat- 
ural to  use  sequences  which  we  now  introduce. 
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A  sequence  of  vectors  in  OL/2  is  declared  and  referenced  as 
shown  in  Figure  1.5.1.   The  mathematical  notation  zW  is  replaced 
by  z[k] . 


LET  A  AND  B  BE  MATRICES  OF  ORDER  (N)   AND  t  tup 
IDENTITY  MATRIX  OF  ORDER  (N);   LET   u   v  AND  w  RF 
VECTORS  OF  ORDER  (N),  AND  c  AND  s  SCALARS-   LE?  z!k] 

BE  A  SEQUENCE  MODC2)  OF  VECTORS  OF  ORDER  (N); 

INPUT  A,  v;   OUTPUT  A,  v; 

s  =  2/2.6;   B  =  I  -  S*A;   w  =  s*v; 

c  =  0.0001  ;   m  =  20; 

z[0J  =  0;   z[l]  =  C; 

COMPOTE?  k  =  °'  ''  —  'm  °RUNTIL   MzCk+l]  -  z[k]||<c; 
zCk+l]  =  B*z[k]  ♦  w; 


Figure  l.S.l 

The  k  in  the  declaration  "LET  z [k]  BE  ..."  is  merely  a  dummy  charac- 
ter and  is  included  only  for  readability.   Conceptually,  the  se- 
quence of  vectors  is  infinite;  that  is,  from  the  language  point  of 
view  there  are  no  inherent  limits  to  the  number  of  vectors  in  the 
sequence.   The  only  practical  limits  are  those  imposed  by  the  value 
of  k  which  is  dependent  upon  the  largest  integer  that  the  computer 
can  represent,  or  by  the  computational  barrier  imposed  by  the  number 
of  operations  implied  by  large  matrices. 
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The  "M0D(2)   (moaning  modulo(2))  in  the  declaration  specifies 
the  number  of  vectors  in  the  sequence  z[kj  that  can  be  referenced, 
or  equivalent^,  the  number  of  vectors  of  the  sequence  that  are 
stored  in  memory.   It  also  implies  that  the  subscript  expressions 
in  zfk+l]  and  z [kj  are  to  be  evaluated  modulo(2).   Thus,  storage 
is  allocated  for  two  vectors,  each  having  n  components.   When  2[1] 
is  computed  as  a  function  of  z[0]  there  is  storage  to  hold  both 
vectors;  when  z[2]  is  computed  as  a  function  of  z[l]  we  use  the 
storage  which  coincides  with  z[0]  for  z[2].   ,t  is  clear  that  this 
process  generalizes  so  that  one  can  reference  the  most  recent  j 
vectors  in  the  sequence  by  writing  MOD(j)  instead  of  M0D(2).   This 
would  allow  one  to  compute  the  j-th  vector  of  a  sequence  as  a  func- 
tion of  the  previous  j-1  vectors.   It  is  clear  that  sequences  of 
arrays,  as  defined  here,  are  more  efficient  than  the  "equivalent" 
method  which  uses  different  variable  names  for  successive  elements 
of  a  sequence.   Evaluating  a  subscr.pt  expression  modulo  some  numbe, 
is  much  faster  than  copying  n  components  during  each  iteration. 

Sequences  of  matrices  are  declared  and  referenced  in  a  similar 
■anner.  ,n  fact,  the  idea  carries  through  to  all  of  the  data  types 
which  we  define  later.   For  instance,  we  can  write: 

LET  A|k|  BO  A  SEQUENCE  M01)(j)  OF  MATRICES  OF  ORDER  (n); 

Sequences  of  sca!ars4  are  also  convenient,  but  the  argument 
of  efficiency  breaks  down  in  this  case.   Nevertheless,  from  the  lan- 
guage point  of  view  they  should  be  allowed. 


4 
icalirs   h^,'{2  comPuilcr  (version  3)  does  not  inelu, 

'hapten  arri!;:,'„^c5.scquen"s  of  arra^s  "»<«»« 
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ELEMENT  BY  ELEMENT 
OPERATIONS  (88  character  set) 

OA  0  B 

C=A  0  B 

C=A  ffl  m 

OF(A) 

where  Fc{SlN,  COS,  TAN,  etc.) 


DEFINITION 

(for  all  i,j) 

cij=aijxbij 

cij=aij/bij 

b.  .^0 

m 
Cif3ij 

m  integer 

-if¥^iP 

RELATION 

A  <  B 

A  <  B 

A  =  B 

A  >  B 

A  >  B 

A  f  B 


DEFINITION 

(true  if) 

a. .  <  b. .  for  all  i, j 
i  J     i  J 

a  <  b -   for  all  i , j 

ij  -  i] 

a. .  =  b.   for  all  l, j 
i]     !J 

■ a  >  b.   for  all  i , j 

ij  ~  13 

■  a.  •  >  b.   for  all  i, j 
13     13 

a  4   b- -  for  some  i, j 
13     13 


SET  RELATION 

s  IN  A 
s  -  IN  A 


DEFINITION 
(true  if) 

s=a-H  for  some  i,j 
s^a-[j  for  all  i,j 


FIG   1  7.1   The  arrays  above  must  be  conformable .   Si: 

tions  apply  to  one-dimensional  "rays.   The  operation 

ffl   and  F(  )  are  not  in  version  3  of  the  OL/2  compil 


Similar  def in: 
s 
er . 
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1,6   Other  Primitive  Operations 

In  many  algorithms  it  is  convenient  and  sometimes  necessary 
to  have  other  array  operations.   m  Figure  1.6.1 'we  define  some 
of  these  operations.5 

It  is  clear  that  some  discretion  must  be  used  with  the  matrix 
inverse.   since  there  are  many  different  algorithms  for  A"1,  and 
since  the  explicit  inverse  is  seldom  needed,  it  seems  appropriate 
to  encourage  users  to  write  their  own  array  algorithms  in  OL/2 
to  fit  their  particular  needs.   since  OL/2  is  an  algorithmic  array 
language,  the  task  is  much  easier  than  writing  the  algorithms  in 
a  high-level  language,  provided  one  has  a  thorough  knowledge  of 
algorithms.   If  this  is  not  the 


reliable  procedure  for  A-1 


case,  then  a  user  should  have  a 
,  even  if  there  is  the  possibility  of 


gross  misuse. 


1-7   Additional  Algebraic  Structure 

The  primitive  array  operations  we  have  introduced  so  far 
°»ey  the  algebraic  rules  of  linear  algebra.   This  is  sufficient 
for  a  large  class  of  problems  which  arise  in  applications  in  engin- 
eering and  science.   We  will  verify  this  claim  when  we  see  how  those 
Iterations  are  used  in  conjunction  with  the  other  operations  and 
lata  types  described  in  the  next  chnpt, 
■till  some  interestim 


pters.   However,  there  are 
algorithms  such  as  integration,  func 
:ion  approximation,  and  finite  differences  that  require  different 
'Igebraic  operations.   The 


■ef Lned  in  Figure  1.7.1 


se  are  the  element  by  element  operations 


ompile?    lL    o'/Z  °nS  ar°  n0t  in  VERSI™  3  of  the  0 

hown,  exco    A'   s         /r'^  the  6°  cha™cter  set  is  t 

ePt  A    ls  replaced  by  A**(-|)  and  At  (m)  by  A**(m) 


OL/2 
he  same  as 
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SYMBOLS  (for  simplicity,  assume  i  ,  j  ,k-l , 2 , . . . ,n) 

3-dimensional  arrays 

B=(bijk)    ,    C=(cijk)    ,    D=(dijk) 

2-dimensional  arrays  (matrix) 

1-dimensional  arrays  (vectors) 
x=(Xi)     ,   y-CTii) 

Scalar 
s 

ARRAY  operation  ff™n°i,:,k) 

n 
A  =  Bxx  aij  =  kl1bij^ 

n   n 
Z  -  Bxxxy  Zi  =  X,    J^iJk^J 

D  =  B+C  dijk  =  bijk  +  Cijk 

D  =  sxB  dijk    SX  ijk 

d.  .1  =  b.,  • 
D  -=  B1  .13k    ik] 


higher  dimensional  arrays  and  matrices. 


27 
Element  by  element  operations  are  found  in  APL,  PL/1  and 

other  languages.   However,  these  operations  are  not  very  useful 
when  they  operate  on  whole  arrays.   We  will  see  in  Chapter  3  that 
we  need  another  array  operation  to  write  algorithms  using  these 
clement  by  element  operations. 

in  Section  2 . 7  we  introduce  three  dimensional  arrays  and 
define  algebraic  operations  which  allow  us  to  combine  three  dimen- 
sional arrays  with  matrices,  vectors,  and  scalars  in  a  natural 
way.   For  instance  in  Figure  1.7.2  we  define  how  the  three  dimen- 
sional array  B  operates  on  a  vector  x  in  one  case  and  how  it 
operates  on  a  pair  of  vectors  x  and  y.   These  ideas  may  be  exten- 
ded to  higher  dimensional  arrays  and  are  important  in  the  study 
of  nonlinear  operator  equations  [11,  7]. 
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CHAPTER  2 
GEOMETRIC  STRUCTURE  -  DATA  TYPES 

2 . 1   Introduction 

Many  array  algorithms  require  data  types  which  are  more  gen- 
eral than  the  rectangular  and  square  arrays  used  for  matrices  and 
vectors.   Arrays  which  can  be  classified  according  to  their  geo- 
metric shape  are  called  geometric    data    types.       This  geometric 
structure  is  independent  of  the  algebraic  structure  discussed  in 
the  last  chapter. 

By  combining  the  geometric  and  algebraic  structures,  one 
imbues  an  array  language  with  many  interesting  properties.   Most 
of  these  properties  cannot  be  exhibited  until  we  cover  more 
aspects  of  the  Of./ 2  language,  but  we  shall  mention  a  few  of  the 
main  characteristics.   Array  algorithms  arc  more  "natural,"  i.e., 
they  convey  their  meaning  through  direct  and  easily  understand- 
able statements  which  correspond  to  the  mathematical  formulation 
of  the  algorithm.   Secondly,  the  execution  of  such  algorithms 
tends  to  be  efficient  in  the  sense  that  the  number  operations  can- 
not be  improved  by  using  an  element  language,  and  memory  space 
used  is  often  of  the  same  order  of  magnitude.   Finally,  array  ■ 
algorithms  are  not  limited  to  linear  algebra,  but  lend  themselves 
to  many  other  applications  as  well. 
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TABLE  I   Geometric  Arrays 


ARRAY  TYPE 


STRICTLY  LOWER 
TRIANGULAR 


DIAGONAL 


STRICTLY  UPPER 
TRIANGULAR 


TRIDIAGONAL 


VIRTUAL 
BOUNDS 


1:N   1:N 


LOWER  TRIANGULAR    1:N   1:N 


1:N   1:N 


1:N   1:N 


UPPER  TRIANGULAR    -1:N   1:N 


1:N   1:N 


STORED  ELEMENTS 


1  <  J  <  I  <  N 

1  <  J  <  I  <  N 
1  <  I  =  J  <  ■  N 
1  <  I  <  J  <  N 

1  <  I  <  J  £  N 

1  I  "  J I  1   1 ■'>'■ 

1  <  I,  J  <  N 


RECTANGULAR 


1:M   1:.N 


1  <  I  <  M; 
1  <  J  <  N 


30 
2-2   Geometric  Data  Types 

The  basic  data  types  are  displayed  in  Table  1.   The  geometry 
of  the  array  is  defined  by  an  attribute  which  designates  the  type 
of  array.   The  virtual  bounds  define  the  lower  and  upper  bounds 
for  the  rows  and  columns  of  each  array  type,  but  the  number  of 
elements  in  any  row  or  column  are  determined  by  the  geometry  of 
the  array.   If  I  refers  t0  the  ,.th  row>  ^    (  ^  ^  ^  ^^ 

of  an  array,  then  tho  elements  which  are  stored  are  defined  by  the 
relations  in  the  last  column  of  Table  1.   All  other  elements  of 
the  arrays  do  not  exist.   The  virtual  bounds  are  not  necessary, 
but  they  form  a  convenient  parameterization  which  is  natural  for 
many  algorithms. 

The  geometric  data  types  of  Table  1  are  almost  universally 
recognized.   Many  familiar  algorithms  rely  upon  such  geometric 
structures  in  explaining  the  workings  of  the  algorithm.   However, 
the  algorithms  usually  degenerate  into  an  element  by  element 
description  and  the  geometric  structure  is  pushed  into  the  back- 
ground.  Here  we  would  like  to  reverse  the  roles.   We  would  like 
the  geometric  structure  to  be  retained,  as  the  predominant  char- 
acteristic, and  let  the  element  by  element  description  be  implicit 
i"  the  algebraic  structure.   That  is,  if  the  algebraic  structure 
is  based  on  linear  algebra,  then  we  know  precisely  how  the  geo- 
metric arrays  are  to  be  combined;  we  do  not  need  to  bother  with 
the  details--they  can  be  delegated  to  the  compiler.   If  the  algebra 
is  different,  as  is  necessary  in  many  applications,  then  we  merely 
define  the  rules  and  again  delegate  the  details  to  the  compiler. 
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ARRAYJTYPES :   MAUI  PROCEDURE; 

N  =  4; 

L^T  A  BE  A  MATRIX  OF  ORDER  CN);   LET  T  BE  A 
TRIDIAGONAL  MATRIX  OF  ORDER  (II)  ;   LET  L  BE  A  LOWER 
TRIANGULAR  MATRIX  OF  ORDER  CN);   LET  x,  y,  AND  z  BE 
VECTORS  OF  ORDER  CN) ;   INPUT  T,  L,  y;   A  =  0; 

z  =  Txy;  OUTPUT  z,  T,  y; 

A  =  Lf ;    z  =  A*y;  OUTPUT  z,  A,  y; 

z  =  L'xy;  OUTPUT  z,  L1,  y; 
END  ARRAY  TYPES; 


1 

Z   ! 

-1- 

65 

1- 

2- 

266 

3- 

4a5 

4- 

447 

!T 


•1- 
•2- 
■3- 

•4- 


2 
4 
6 


5 
7 

9 


8 
10 


t 

,Y_ 

i 
"1- 

-1- 

21 

-2- 

22 

-3- 

23 

-4- 

24 

c 

Z   i 
-1- 

1225 

1- 

2- 

1063 

3- 

824 

4- 

480 

!A 


-1- 
-2- 
-3- 

-4- 


* 
•1- 

11 
0 
0 
0 


!Y 


-2- 

12 

13 

0 

0 


3- 
14 
15 
16 
0 


•4- 
17 
18 
19 
20 


-1- 

-1- 

21 

-2- 

22 

-3- 

23 

-4- 

24 

■ 

.Z   ! 

-1- 

1- 

1225 

2- 

1063 

3- 

324 

4- 

480 

•L'  * 

♦ 

*    * 

'   i 

1-    11 

12 

14 

17 

2- 

13 

15 

18 

3- 

16 

19 

4- 

20 

-1- 

-2- 
-3- 

-4- 


!Y_  1 

-1- 
21 
22 
23 

24 


Fig.  2.2.1   Examples  of  geometric  data  types    A  blank  in  an 
ar?ay  element  position  indicates  that  physical  st °™Z^S    ™   ( 
required  for  the  element,  and  that  the  element  does  not  expli 
itly  enter  into  the  evaluation  of  the  array  expression  (see 
Section  2.4). 
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The  primitive  algebraic  operations  of  Chapter  1  apply  to  the 
geometric  arrays  we  have  defined.   Thus,  the  declarations  may  be 
modified  by  a  geometric  attribute,  as  indicated  in  Figure  2.2.1. 
For  example,  L£  we  use  linear  aJgebra>  then  ^  ^  ^   ^.^ 

is   algebraically  closed  under  the  operations  of  matrix  multiplica- 
tion and  addition,  provided  we  properly  specify  the  dimensions  of 
the  matrices  and  the  types  of  numbers.   But  what  about  geometric 
closure?   If  we  multiply  „  tridlagonal  ^^    by  _  ^  trianguiap 

matrix,  as  in  figure  2.3.1,  then  what  is  the  geometric  shape  of  the 
resulting  matrix? 

We  emphasize  that  the  array  expressions  Axy  and  L'xy  are  alge- 
braically equivalent  but  not  geometrically  equivalent.   That  is, 
the  value  of  z  is  the  same  in  both  cases,  but  internally,  Axy  re- 
quires that  the  zero  elements  enter  into  the  evaluation,  whereas 
•n  L'xy  the  zero  elements  do  not  exist  and,  hence,  cannot  enter 
into  the  evaluation.   Thus,  L'xy  is  more  ef  f  i  c  i  en  t  ■  -  in  terms  of  both 
-mory  space  and  computation.   This  statement  applies  to  all  of  the 
array  typos  we  shall  define. 


arrays,  then  we  must  be  able  to  combine 
ay  that  we  have  both  algebraic-    closure    and  qeo- 


2  '  3   ljeoinet_rLc  Closure 

Tf  we  define  geometric 
them  in  such  a  w 
me  trio    closure. 

Metric   clour..      IT.  say  that  the  set  S  of  array  types 
defined  in  Table  1  is  geometrically  cio 

A,  Br;S  imply  A°BeS 


y  closed  under  an  operation  °  if 
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CLOSURE:      MAIN   PROCEDURE; 

N    -    4; 

LET  A  BE  A  MATRIX  Or  ORDER  (N)  ;   LET  T  BE  A 
TRIDIAGONAL  MATRIX  OF  ORDER  (N)  J  LET  L  BE  A  LGMER 
TRIANGULAR  MATRIX  OF  ORDER  (II)  J   INPUT  T,  L; 
INITIALIZE:  A  =  -1  ; 

A  =  T*L;        OUTPUT  A,  T,  L ; 
A  =  L*T;       OUTPUT  A,  L,  T; 
END  CLOSURE;  •  , 


•A  * 

* 

* 

t 

• 

1-   35 

26 

0 

0 

2-  151 

127 

80 

0 

•3-  30b  327  264  160 
•4»  296  315  334  200 


IT  * 

* 

* 

i 

-1-    1 

2 

-2-    3 

4 

5 

-3- 

6 

7 

8 

-4- 

9 

10 

* 

A  * 

* 

* 

i 

1- 

11 

22 

0 

0 

2- 

51 

76 

65 

0 

3- 

59 

184 

187 

128 

4- 

71 

220 

403 

352 

•L  * 

* 

* 

i 

-1-   11 
-2-   12 
-3-   14 
-4-   17 

13 
15 
18 

16 
19 

20 

!L  * 

* 

* 

i 

-1-   11 

-2-   12 

13 

-3-   14 

15 

16 

-4-   17 

18 

19 

20 

lT  *   *   *   1 
*_1_  -2-  -3-  -4- 

-1-    1  2 

-2-3  4  5 

-3-  6  7    8 

-4-  9   10 


Fie   2.3.1   Example  showing  how  a  tridiagonal  array  and  a  lower_ t ri- 
a^ular  array  car!  be  coined  under  the  operation  o   matrix  mu Itip li« 
tin  to  produce  a  lower  Hessenberg  array.   Geomotrl\^°^f_  ■*   the 
by  imbedding  the  Hessenberg  array  in  a  square  array  and  defining  the 
remaining  elements  to  be  zero,  which  is  consistent  with  the  aigenra 
operation . 
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CLOSURE:   MAIN  PROCEDURE; 


J  =  4; 


LET  A  AND  B  BE  MATRICES  OF  ORDER  (N) •   LET  T  PV 

A   STRICTLY  LOWER  TRIANGULAR  MATRIX  OF  ORDER  (i).   fr~  n 


A  =  L  +  U;      OUTPUT  A,  L,  U; 
B  =  LxL;        OUTPUT  D,  L; 


END  CLOSURE; 
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rious  operations  t   »™3?  that  £co™etric  ty^cs  m^  be  combined  under 
ly  the     !     ,  °  <uoduce  irregular  geometric  shapes.   Notice  that 
V   tlit  stuctly  lower  triangular  part  of  Bis  changed 
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MULT  I  PL  J.C AT  TON  OF  GEOMETRIC  TYPES  X  x  Y 


SLT 


TD 


SUT 


SLT 


LT 


si; 


si;r 


LT 


TD 


UT 


SLT 


LT 


TO 


LIT 


sin 


UT 


SUT 


SUT 


SUT 


n 


R. 


R 


R 


ADDITION  OF  GEOMETRIC  TYPES  X  +  Y 


X 


S   x 


SCALAR  MULTIPLICATION  s  *  X 


SLT 


SLT 


LT 


LT 


I'D 


TD 


UT 


UT 


SUT 


SUT 


R 


SLT  =  Strictly  Lower  Triangular 
LT   =  Lower  Triangular 
TD   =  Tr id i agonal 


D  =  Diagonal 

UT  =  Upper  Triangular 

SUT  -  Strictly  Upper  Triangular 

R  -  Rectangular  or  Square 


Multiplication,  addition,  and  scalar  multiplication 
The  geometric  shape  of  the  result  is 
half  of  the  table,  since  the  table  is 


Fig.  2.5.3 

of' geometric  data  types 
displayed  only  in  the  upper 
symmet  r  i  c - 
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The  example  of  Figure  2.3.1  shews  that  set  S  is  closed  only 
because  we  have  filled  out  the  result  L*T  with  zeros.   If  we  had 
net  done  this,  we  would  have  had  a  lower  Hessenberg  form  which  Is 
not  an  array  type  in  Table  1.   Probably  lower  and  upper  Hessenberg 
forms  should  be  included  in  Table  1  because  of  their  frequent  use 
in  algorithms.   However,  extending  the  set  S  of  basic  typos  would 
not  solve  the  closure  problem  because  other  unusual  geometric 
shapes  can  emerge.   for  instance,  in  figure  2.3.2  we  combine 
strictly  lower  triangular  and  strictly  upper  triangular  under  the 
operations  of  matrix  addition  and  matrix  multiplication. 

Geometric  closure,  therefore,  is  obtained  by  putting  the 
result  into  the  smallest  array  type  of  Table  1  that  can  hold  the 
result  and  assigning  zero  to  all  undefined  elements.   It  is  impor- 
tant to  notice  that  thus  is  consistent  with  the  algebraic  structure 
which  we  have  imbedded  into  01/2.   ,„  Figure  2.3.3  we  exhibit  geo- 
metric closure  under  the  operations  of  matrix  multiplication, 
matrix  addition,  and  scalar  times  matrix. 

2.4   Implicit  and  Explicit  Clements 


For  non- rectangular  arrays,  certain  elements  do  not  exist 
because  memory  space  is  not  allocated  for  them.   For  instance,  if 
J  ts  lower  triangular,  then  a  reference  to  any  element  above  the 
main  diagonal  is  undefined.   However,  with  an  algebraic  structure 
<»    the  language,  we  can  give  meaning  to  these  nonexistent  elements, 
»"d  we  call  these  elements  implicit    because  they  obey  the  alge- 
braic rules  without  requiring  physical  storage.   All  other  elements 
we  i.i  I  I  explicit. 
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SYM:   MAIN  PROCEDURE; 

N  =  4  ; 

LET  S  BE  A  SYMMETRIC  MATR'X  OF  ORDER  (N)j 
Lv7  A  BE  A  MATRIX  OF  ORDER  (N)  ;   LET  U  BE  AN 
UPPEP  TRIANGULAE  MATRIX  OF  ORDER  (N); 
A  =  -1  ;   INPUT  3,  U; 

A  =  Ui  OUTPUT  A,  U; 

A  =  S;  OUTPUT  A,  S; 

A  =  SxS;  OUTPUT  A,  S,  S :. 

A  -  IJxU;  OUTPUT  A,  U,  U; 

\    =  -UT  +  U;   ■  OUTPUT  A,  U; 
END  SYM; 
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FIG   2  5.1   Comparison  of  operations  with  symmetric  and ^ upper  tn 
angular  matrices.   Note  A=UxU  changes  only  the  upper  triangular 
part  of  A.   Both  U  and  S  are  stored  as  upper  triangular  arrays. 
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It  is  clear  that  the  operations  of  linear  algebra  define  all 

implicit  elements  to  he  zero;  however,  in  Section  2  ,  5  we  soo  that 
nonzero  implicit  elements  also  occur  quite  naturally.   ,n  the  last 
section  wc  saw  that  geometric  closure  forced  us  to  insert  "explicit 
zeros"  into  the  result  of  certain  matrix  operations  in  order  to 
fill  out  the  array.   This  choice  was  determined  by  the  algebra. 

in  view  of  the  above  statements,  it  is  possible  to  reference 
an  implicit  element  in  an  array  expression  and  to  give  an  unambig- 
uous meaning  to  the  rcsul t -- because  it  behaves  like  zero.   The 
only  reason  for  allowing  such  a  reference  would  be  to  allow  for 
a  dynamic  situation  in  which  the  programmer  would  not  have 
a  prior,  knowledge  about  its  use.   ,n  fact,  i„  the  next  chapter, 
we  define  null,   operand,    which  w  i  .11  include  "implicit  zero,"  along 
with  some  arrays.   As  we  shall  show,  it  is  bettor  to  include  such 
operands  than  to  try  to  exclude  them,  because  it  enhances  the 
language  and  because  it  is  not  difficult  to  implement. 

2.5  Algebraic  and  Cleometrii-  Data  Types 

~  — ' ■    ■■  - '        * 

The  geometric  data  types  are  efficient  data  structures  which 
.'educe  storage  and  minimize  the  number  of  operations  in  an  array 
language;  they  also  provide  a  natural  form  that  corresponds  to 
the  way  we  think  about  array  problems.   However,  some  additional 
data  types  should  be  considered  which  have  inherent  algebraic 
st  rue  t  urc  . 

A  symmetric  matrix,  defined  by  A=A',  offers  the  first  example. 
Wc  use  the  convention  of  storing  only  the  upper  triangular  part  of 
"'is  matrix  as  shown  ,„  Ktgure  2.5.1.   The  user  does  not  need  to 


know  how  a  symmetric  matrix  is  implemented,  except  to  conform  with 
input-output  conventions.  A,  ]  he  reaily  needs  to  know  is  whether 
the  use  of  it  is  mathematically  correct.   m  array  expressions,  a 
symmetric  matrix  which  is  stored  as  a  triangular  array  requires  as 
many  operations  in  the  evaluation  of  an  array  expression  as  a 
symmetric  matrix  which  is  stored  as  a  square  array.   Thus,  no 
computational  effort  can  be  saved;  this  Ls  in  contrast  to  the  geo- 
metric arrays  in  the  previous  section  which  require  considerably 
i  ewer  opera  I  i  oris  . 

It  is  clear  that  a  symmetric  matrix  and  an  upper  triangular 
matrix  obey  different  algebraic  rules  -even  though  they  are  both 
•stored  as  upper  triangular.   in  terms  of  the  implicit  elements 
of  the  previous  section,  we  interpret  implicit  non-zeros  in 
vase  and  implicit  zeros  i„  the  other.   if  technology  in 
'Hanged  so  that  storage  was  net  a  problem,  i,  mil,  stllJ  be  prefcr 
able  to  store  symmetric  matrices  as  triangular  arrays--in  order  to 
guarantee  mathematical  symmetry  and  avoid  side  effects  that  may 
occur  as  a  result  of  using  different  types  of  arithmetic.   For 
this  reason  we  classify  some  arrays  by  both  their  algebraic  and 
geometric  structure. 

Along  with  symmetric  matrices  one  may  consider  anti -symmetric 
'""trices,  winch  are  defined  by  algebraic  property  that  A'-Aj  or 
o»e  may  consider  Hcrmltian  matrices  winch  arc  defined  by  AH=A 
"here  A   is  the  conjugate  transpose  of  A.6 

"al;6otherw?Se\t%eno%U°AHen0Ant^  'T?0"  ,f  A  Whe"  A  is 
""not  include,  in   version  a   ofthe^/  ^compiler?"™1  '  '  '"  ""  '  '  C" 


s 
one 
memor  ies 
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There  arc  other  types  of  matri 


ces  which  we  have  not  considered 
■or  instance,  an  orthogonal  Matrix  which  has  the  algebrarc  property 


that  A'=A 


It  al so  ha 


as  the  topological  property  that  its  eigen 
values  have  absolute  value  of  unity.   The  data  structure  for  a 
symmetric  matrix  can  guarantee  symmetry,  but  the  data  structure  f 
an  orthogonal  matrix  which  may  also  be  represented  by  an  upper  tri 
angular,  cannot  guarantee  orthogonality.   This  provides  a  natural 
division  between  what  is  presently  implementabl e  and  what  is  not. 
In    the  latter  we  would  also  put  unit 
tive  semi  -definite,  and  oth 


or 


ary,  positive  definite,  posi- 
er  matrices  with  topological  structure. 


ypes 


2  .  6   Geometric  Operators 

Geometric   operator   will  be  used  as  a  general  term  to  refer  to 
arrays  which  have   both  geometric  and  algebraic  structure.   The 
geometric  data  types  such  as  lower  triangular  matrix  and  diagonal 
«trix  are  examples  of  geometric  operators.   In  this  section  we 
extend  the  class  of  geometric  operators  by  adding  the  data  t 
that  wore  first  mentioned  in  Section  1.7. 

First,  we  introduce  3-dimensional  arrays  into  the  language. 
We  denote  by  B  a  p*qxr  array,  with  elements  „...,  where  1  <  i  <  D 

■  J   ■  q'  and  [  "  k  '  r-   An  example  is  shown  in  Figure  2.6.1b. 
*>  far,  this  array  is  no  different  from  any  other  3-dimensional 
pray  in  most  languages- -it  has  only  a  primitive  geometric  struc- 
ture and  no  algebraic  structure. 


We  introduce  algebraic  structure  by  defining  ho 


w 


ate  on  vectors .   I f 


i  s  to  opcr- 


»  y,  and  z  are  vectors  with  n  components, 


_ 


41 
an  nxnx„  array,  then  we  define  Bx  to  be  a  matrix  A  whose  elements 
are  defined  by 


1 1 

a  ;  \    =    J  b.  .,  x. 


'  J  -  1 ,  2  ,....,  n , 


nd  we  define  Bxy  to  be  a  vector  z  whose  components 


are  defined  by 


n    n 


i  =  .^aij^j  =   I   I   b,. 
.1-1  J  J   j  =  i  k=l  XJ 


ikxkyi   x  =  1'--->n 


In  other  words,  B  is  a 


ni 


,n  „n 


apping  from  R  xR»    to  Rn ,  or  equivalently  a 


mapping  from  R   into  the  set  of  n<n  matrices. 

From  the  definition,  it  follows  that  B  is  additive  m  each 


argument 


B(x+y)z  =  Bxz+Byz 


Bx(y+z)  -  Bxy+Bxz 


It  also  follows  that  if  a  is 


B(ax)y  =  aBxy 


a  real  number,  then  B  is  homogeneous 


Bx(cxy)  =  uBxy. 

■  he    above    properties    dofinr*    •■    /  •  /  • 

V      perries  define  a  bilinear    operator,    or  equivalently,  a 

bilinear   matrix    when  the  underlying  spaces  are  Rn . 7 

We  will  not  be  concerned  wi.th  the  mathematical  properties  of 
these  operators.   Our  previous  discussion  was  intended  to  show 


7T] 
tors  (ai 


ie  mathematical  and  computational  details  of  bilinear  oner- 
el  other  operators)  are  described  in  fill.     ,linear  °Por< 
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Array  Symbol 


Ik 


h  - 


i  2k 


«  b. 


i3k 


i  b 


4  k 


(a)  elements  of  E 


£ 


(b)  cubic 


J  \ 


(c)  semi -cubic 


^1 


[d]  tctrah'eilral 


FIG   2.6.1   Two  aimoa.sio.na]  ami  t:.;:;ree-cJimonsional  represent,- 
Hon,  of  stored  elements  for  oeomefric  operators  corresponding 
to  'bilinear*  symmetric  bilinear;  ami  sclf-«djoint  operators. 
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justification  for  the  inclusion  of  more  general  operators  in  an 

array  language.  Furthermore,  the  algebraic  structure  is  a  natural 
generalization  of  the  algebraic  structure  associated  with  matrices 
and  vectors. 

We  turn  now  to  the  geometric  data  types  for  3- dimensional 
arrays.   Corresponding  to  the  arrays  in  Table  1,  we  could  define 
an  upper  triangular  (3 -dimensional)  array.   However,  it  is  no 
longer  clear  what  we  mean  by  this,  because  the  use  of  such  arrays 
is  not  part  of  our  experience.   For  instance,  a  3 -dimens ional 
upper  triangular  matrix  could  mean  a  sequence  of  "upper  triangular 
layers"  as  displayed  in  Figure  2.6.1c.  On  the  other  hand,  it  could 
mean  a  sequence  of  upper  triangular  layers  which  decreased  (or 
increased)  uniformly  in  size  as  shown  in  Figure  2. 6. Id.   Clearly 
there  are  other  choices,  and  we  could  enumerate  all  of  then  by 
viewing  the  symmetry  of  a  cube  which  would  contain  them.   Since 
there  are  so  many  possibilities  and  so  little  experience  with  a 
3-dimensional  geometric  types,  we  limit  our  choice  to  three  basic 
forms  which  are  determined  primarily  by  algebraic  considerations. 
Let  B  be  an  n*nxn  (bilinear)  matrix  and  denote  its  elements 

by  b..k.  if 

bijk  =  bikj     for  al1  i.J.k 

then  B  is  said  to  be  a  symmetric:  bilinear  matrix.  Therefore,  it 
1S  Clcar  that  B  can  be  represented  by  a  sequence  of  n  upper  tri- 
angular arrays  as  in  Figure  2.6.1c.  As  it  turns  out,  most  iterative 
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algorithms  use  symmetric  bilinear  matrices  and  many  of  the  algor- 
ithms arc  variants  of  Newton's  method  for  systems  of  nonlinear 
equat  ions  [1 1J  . 

The  second  3 -dimensional  geometric  type  arises  from  the  follow 
ing  definition.   if  for  all  i,j 


and 


bijk  =  bikj 


bijk  =  bjik 


then  B  is  said  to  be  a  self-adjoint 


bit 


■meav   matrix.        in    this    cast 


B    can    be    represented    b 


y    a    sequence    of   upper    triangular    arrays    of 


order   n,    n-1,    n-2,     ...,    1    respectively,    as    shown    in    Figure    2.6.3. 
These    data    types    have    both    geometric    and    algebraic    structure 
and,    therefore,     fall    into    the    same    class    as    symmetric    and    anti- 
symmetric    matrices. 


2-7      £ojTUTC^u_te    Data    Types 


XEi^L_JiJil£LAr2^L 


Th 


e  basic  data  t 


a  types  of  Table  1  may  be  used  to  form  other 
-Portant  data  types.   For  example,  the  bloc*  tridlagonaJ  matrices 
which  ar.se  so  often  ln  the  numerical  solution  of  partial  differen- 
tial equations,  are  easy  to  construct  and  are  efficient  to  use. 
|      A  typical  example  of  a  block  trul, agonal  matrix  is  as  follows: 

»lAliiiCL&  01  ORDER  (:;>;   LET  ... 
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This  sequence  may  be  used  to  form  the  diagonal  blocks.   If  all  of 

the  blocks  have  identical  values  then 


a  sequence  is  not  necessary 
and  storage  is  conserved.   The  other  blocks  in  a  block  tridiagonal 
matrix  may  be  declared  as  follows: 

...  OF  0RDi::\    (ID-   LET  LCk]  AND  U[k]  BE  SEQUE\TCFS 
IIOD(Il-l)  OF  DIAGONAL  MATRICES  OF  ORDER  (E);   


The  combination  of  L[k],  TfkJ,  and  U[kJ  yield  a  compact  data  str 
ture  as  shown  in  Figure  2,7.1. 

It  is  possible,  therefore,  to  add  a  new  composite    data  type 
called  block    tridiagonal.        It  should  be  clear  that  a  band   matrix 
also  may  be  constructed  from  a  block  tridiagonal  matrix  if  we 
choose  the  upper  blocks  to  be  lower  triangular,  the  diagonal 
blocks  to  bo  square,  and  the  lower  blocks  to  be  upper  triangular 
The  storage  for  a  dense  band  matrix  is  therefore  optimal. 


uc 


i.;k; 
ma  t  i 


\'\'\    ,Tu°  composite  data  types-   a  sparse  bio  i  tridiaeona 
*    ,,nd  ''  K,,(1  m.-itrix.   The  storage  for  each  is  optimal.  ' 
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The  algebraic  operations  which  we  have  defined  may  be  applied 

to  combine  the  block  arrays  with  vectors.   Iterative  or  direct 
methods  may  be  used  with  these  composite  data  types,  but  some  of 
the  techniques  are  dependent  upon  the  notions  in  Chapter  3,  and 
therefore  cannot  be  fully  explained  here. 

The  composite  data  types  of  band  matrix  and  block  tridiagonal 
matrix  are  included  in  the  OL/2  language  but  are  not  implemented. 
That  is,  we  cannot  declare  a  band  matrix  directly  but  must  con- 
struct it  from  the  basic  types  of  geometric  arrays.   However,  it 
is  important  to  note  that  the  existence  of  the  basic  data  types 
provides  a  natural  framework  for  extending  the  class  of  geometri 
data  types  and  it  provides  a  basis  for  the  implementation  since  « 
information  structure  for  the  n 


c 

an 
ew  composite  data  types  can  be  built 


°Ut.°f  th°  inf0™ati™  structures  that  are  used  for  the  basic  data 
types . 
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CHAPTER  3 
DYNAMIC  PARTITIONING 


3.1   Introduction 


In  the  previous  chapters  we  have  introduced  some  primitive 
array  operations,  along  with  a  fairly  rich  set  of  algebraic  and 
geometric  data  types.   We  have  shown  how  composite  data  types  may 
be  constructed  from  basic  data  types,  and  we  have  shown  how  sequen- 
ces of  arrays  can  be  declared  and  used  in  a  natural  and  efficient 
manner.   We  have  even  demonstrated  the  utility  of  the  language 
with  some  familiar  applications.   But  an  array  language  with  these 
features  is  not  sufficient;  there  are  large  classes  of  algorithms 
which  cannot  be  wr i t ten  - -even  if  we  add  such  things  as  IF  state- 
ments, WHILE  clauses,  procedures,  block  structure,  and  other  lan- 
guage facilities.   What  we  need  is  a  new  array  language  construct 
which  allows  us  to  fully  utilize  all  of  the  array  operations  and 
data  types  we  have  discussed.   This  is  the  purpose  of  dynamic- 
partitioning.   Further  details  are  contained  in  [8,  9]. 

Dynamic    partitioning    is  the  process  of  partitioning  an  array 
into  subarrays  and  allowing  the  subarrays  to  vary  over  the  original 
array  in  a  nearly  arbitrary  manner.   In  its  most  general  form, 
dynamic  partitioning  allows  a  subarray  to  vary  its  position,  its 
size,  and  its  shape  during  program  execution.   Being  able  to  refer- 
!  ence  subarrays  instead  of  whole  arrays  is  essential  to  the  process 
of  constructing  efficient  array  algorithms.   Perhaps  the  most 
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49 
pleasant  surprise  is  that  partitioning  is  an  efficient  operation 
in  the  sense  that  the  number  of  operations  cannot  be  reduced  by 
clement  languages  and  storage  can  be  reduced  only  in  certain 
instances . 

3.2   Closure  for  Partitioning 


The  simplest  form  of  partitioning  is  static   partitioning. 
This  consists  of  the  familiar  process  of  separating  an  array  into 
subarrays  by  inserting  fixed  partition  lines  between  certain  rows 
and  columns  of  an  array.   However,  we  extend  this  process  by  allow 
ing  partitioning  to  operate  on  all  of  the  basic  data  types  defined 
in  Chapter  2.   Figure  3.2.1  illustrates  static  partitioning  for 
several  of  the  geometric  data  types. 

Partitioning  is  defined  in  such  a  way  that  the  set  of  data 
types  remain  closed  under  the  operation  of  partitioning.   That  is, 
every  subarray  which  results  from  partitioning  must  be  one  of  the 
data  types  in  Table  1  of  Chapter  2.   Thus,  we  define  partitioning 
for  all  triangular  and  diagonal  arrays  by  having  the  partitioning 
line  reflect  off  of  an  imaginary  diagonal  line  which  starts  in 
the  upper  left  corner  of  the  array  and  proceeds  to  the  lower  right 
orner.   Since  these  arrays  are  square,  by  definition  of  the  vir- 
tual bounds,  the  effect  is  to  simultaneously  partition  the  array 
after  the  same  row  and  column. 

Rectangular  arrays,  on  the  other  hand,  are  partitioned  in 
the  usual  way.  That  is,  they  are  partitioned  after  any  row  or 
:olumn  of  the  array  with  the  row  and  column  partitioning  lines 
being  independent  of  each  other. 
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Another  mode  of  partitioning,  which  is  referred  to  as  diag- 
onal partitioning,  is  also  defined.   To  simplify  matters  assume 
that  the  array  to  be  partitioned  is  a  square  array  of  order  n. 
Then  one  may  specify  any  part  of  the  matrix  which  is  compatible 
with  one  of  the  triangular  or  diagonal  arrays  in  Table  1;  for 
example,  one  may  specify  the  strictly  upper  triangular  part  of 
an  array.   This  is  equivalent  to  placing  a  diagonal  partitioning 
line  just  above  the  principal  diagonal  of  the  array  as  shown  in 
part  (e)  of  Figure  3.2.1 . 

We  extend  partitioning  into  the  dynamic  realm  by  allowing 
the  partitioning  lines  to  be  defined  by  expressions.   Thus,  in 
dynamic   partitioning    the  subarrays  vary  over  the  parent  array 
in  a  nearly  arbitrary  manner  as  the  values  of  the  (partition) 
expressions  change.   In  all  cases  of  partitioning,  it  is  neces- 
sary for  the  set  of  data  types  to  remain  closed  under  the  opera- 
tion of  partitioning.   We  will  impose  some  restrictions  later  in 
order  to  guarantee  closure. 


3-  3   Subarray  Reference 

The  subarrays  which  are  defined  by  the  partition  operation 
are  labeled  in  a  natural  way.   If  A  is  a  rectangular  array  which 
has  been  partitioned  with  two  vertical  lines  and  one  horizontal 
line,  then  we  reference  the  subarrays  in  the  usual  way,  by  using 
the  notation  A<I,J>  to  denote  the  subarrays. 


A<1,1> 


A<2,1> 


A<1,2>     |   A<1,3> 


A<2,2> 


PIG.  3.3.1 


A<2,3> 


iL 
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PARTITIONING:      MAIN    PROCEDURE; 

II    =    8  ; 

TFT  L  BE  A  LOWER  TRIANGULAR  MATRIX  OF  ORDER  (N); 
PARTITION'  L  AFTER  ROWS  2,  6;   INPUT  L;   OUTPUT  L; 

OUTPUT  L<1,1*  ,  L<2,2»  ,  L<3.,3>  ; 

OUTPUT  L<2,1 >  ,  L<2,2>  ; 

OUTPUT  L<3,1>  ,  L<3,2>  ,  L<3,3>  ; 
END  PARTITIONING; 
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Fig.  3.3.2  Subarray  reference  of  a  partitioned  tower  trianguld 
array.  The  labels  which  normally  appear  in  the  output  have  he; 
removed  bv  a  format  statement  which  is  not  shown. 
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The  special  parentheses  <  >  are  used  for  subarrays  so  that  the 

I  common  parentheses  can  be  used  for  referencing  elements  of  a 
matrix.   Figure  3.3.1  illustrates  the  partitioning  and  refer- 
encing shown  above. 
The  conventional  subscripting  of  subarrays  is  extended  to 
geometric  data  types  in  a  natural  way.   For  instance,  we  parti- 
tion a  lower  triangular  matrix  L,  as  shown  in  Figure  3.3.2,  and 
then  subscript  the  subarrays  as  though  L  were  square.   Therefore, 
L<1,2>,  L<1,3>,  and  L<2,3>  are  undefined  and  cannot  be  referenced 
This  subscripting  convention  applies  to  all  of  the  geometric  data 
types  described  earlier.   Also  observe  that  the  subarrays  on  the 
diagonal  inherit  the  lower  triangular  shape  of  L  while  those 
below  it  are  rectangular. 

A  subarray  reference  such  as  A<3,1>,  is  independent  of  the 
size  and  shape  of  A  and  also  independent  of  the  exact  positioning 
of  the  partitioning  lines;  only  the  number  of  partitioning  lines 
and  their  orientation  (vertical,  horizontal,  diagonal)  are  needed 
i  to  uniquely  define  A<3,1>.   This  allows  us  to  simplify  the  sub- 
array  references  even  further.   We  can  rename  A<3,1>  with  the  use 
of  a  SET  statement  as  shown  in  Figure  3.3.3. 

We  note  in  this  example  that  the  partitioning  is  dynamic 
'  because  of  the  FOR  statement.   The  SET  statement  is  used  to  rename 
two   subarrays  and  each  subarray  is  referenced  with  a  single  vari- 
able name.   This  procedure  is  valid  for  both  static  and  dynamic 
subarrays . 
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SUBARRAYS;   MAIN  PROCEDURE; 

II  =  6; 

LET   A   BE  A  LOWER  TRIANGULAR  MATRIX  OF  ORDER  (M); 
INPUT  A;   OUTPUT  A; 

FOR  K=3,4,...,N-1;   PARTITION  A  AFTER  RONS  K-l ,  K; 
GET  M=A<3,1>,  C=A<3,2>; 

OUTPUT  II,  C; 


EN 

dj 

END  SUBARRA' 

•A  * 

* 

* 

* 

* 

i 

-1-    1 

-2-    2 
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IC  1 

-1- 

-2- 

-1- 

-1-    7 

a 

-1- 

9 
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!U  *  *  !  IC  ! 

-1-  -2-  -3-  -1- 

1-  .  11  12  13  -1-   14 

•  2-   16  17  18  "2-   19 


JM'*    *    *    1  lc  ! 

'_<!-  -2-  -3-  -4-  -1- 

1-   16   17   18   19      -1-   20 


F,„.  3.5,3   Dynamic  partitioning  showing  how  subarrays  may  be 
reference;].   Observe  that  both  the  size  and  position  of  the  sub 
arrays  M  and  C  change.   The  partitioning  used  here  is  the  basis 
for  the  algorithm  in  Figure  3.3.4. 


I  54 

|        In  Figure  3.3.4  we  generalize  the  last  example  by  combining 
|   dynamic  partitioning  with  some  array  expressions  and  array  assign- 
j   ment  statements.   This  time  the  SET  statement  contains  some  attri- 
|   butes.   In  particular,  we  specify  to  the  compiler  which  subarrays 
;   are  to  act  like  row  vectors,  column  vectors,  or  scalars  under 

operation  of  dynamic  partitioning.   Without  these  attributes,  the 
compiler  can  only  assume  that  all  subarrays  are  two  dimensional, 
and  this  means  that  the  precedence  rules  for  evaluating  array 
expressions  will  be  different,  in  general.   Since  efficient  eval- 
uation of  array  expressions  depends  upon  precedence,  as  was  shown 
in  Chapter  1,  it  is  important  to  include  these  attributes  in  SET 
statements . 

It  is  surprising  how  many  array  algorithms  have  subarrays 
which  move  over  parent  arrays  and  still  maintain  their  row  or 
column  vector  shape.   Figure  3.3.4  is  one  such  example,  namely, 

'  the  well-known  Cholesky  decomposition  of  a  symmetric,  positive 
definite  matrix  A  into  the  product  of  a  lower  triangular  matrix 

I  L  and  its  transpose  L'.   That  is,  A  is  replaced  by  L  and  the  alge- 
braic result  is  LxL'=A,  as  shown  in  Figure  3.3.4. 

We  introduce  another  use  of  the  SET  statement  in  Figure  3.3.4, 
namely  "SET  L=A".   This  is  effectively  an  equivalence  statement; 

|  L  and  A  refer  to  the  same  storage  locations.   This  allows  us  to 
write  the  array  expression  LxL'  in  Figure  3.3.4  and  thereby  avoid 
confusion  with  A,  which  was  the  original  array  that  was  replaced 
by  L.   This  "equivalence"  is  really  just  a  special  case  of  set- 
ting a  variable  equal  to  some  subarray,  like  "SET  M=A(3,1)," 
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DECOMPOSITION:       LIAIN    PROCEDURE; 


N    =    H ; 


LET   A   BE  A  LOWER  TRIANGULAR  MATRIX  OF  ORDER  (II); 
SET  L=A;   INPUT  A;   OUTPUT  A; 

FOR  K=1,2,...,N;   PARTITION  A  AFTER  ROUS  K-l ,  K; 
SET  R=A<2,1>  ROW  VECTOR,  D=A<2,2>  SCALAR,  C=A<3,2> 
COLUiiN  VECTOR,  AND  M=A<3,1>; 

D  =  SQRTC  D  -  (R',R')  >i 

C  =  (  C  -  MxR'  )/D; 

END; 

OUTPUT  L  |  LxL1 ; 
END  DECOMPOSITION; 


,A  ************* 
-1-  -2-  -3-  -4- 

1-  5. OOOOOOE+00 

2-  7. OOOOOOE+OO  1.00000QE+01 

•3-      6. OOOOOOE+00  8. OOOOOOE+00  1.O0O0O0E+01 

•  4-      5  OOOOOOE+OO  7.000000E+00  9. OOOOOOE+OO  1.000000E+01 


IL 


*    *    *    * 


*    *    *    *    * 


-2-  -3-  -4- 


-1- 

1-      2.236068E+00 
■2-      3.130495E+00  4.472136E-01 
-3-      2.683282E+00-8.944272E-01  1.414214E+00 
•4-      2.236068E+00  3.97205bE-l5  2.121320E+00  7.071068E-01 

iL*L«  ***********    *1 
_!_  -2-  "3-  -4- 

5  OOOOOOE+00  7. OOOOOOE+00  6. 000000E+00  5. 000000E+00 


■1- 
■2- 

'.il-  V.  OOOOOOE+00  7i000000E+00  g^OOOOOOE+OO  1.000000E+01 


7'000000E+00  1.000000E+01  8. OOOOOOE+OO  7. OOOOOOE+00 
g!oOOOOOE+00  8. OOOOOOE+OO  1.000000E+01  9. OOOOOOE+00 


FIG.  3.3.4   Decomposition  of  a  symmetric,  positive  definite 
matrix  A  into  a  lower  triangular  matrix  L.   Note  A  is  stored 
as  a  lower  triangular  matrix  and  L  overwrites  A.   The  product 
LxL'  yields  the  original  matrix  as  a  full  matrix:  normally  one 
would  not  execute  this  last  stop.   The  algorithm  is  Cholesky 
method . 


J 
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which  could  be  referred  to  as  dynamic    equivalence  .   More  intri- 
cate applications  involving  dynamic  partitioning  and  dynamic 
equivalence  can  be  constructed,  but  they  rely  upon  features  which 
we  have  not  discussed. 

3.4   Null  Operands 

Under  dynamic  partitioning,  it  is  possible  for  a  partition- 
ing line  to  fall  on  the  boundary  of  an  array,  to  fall  outside 
the  boundary,  or  to  be  superimposed  upon  another  partitioning 
line.   All  of  these  possibilities,  besides  the  usual  well  defined 
cases,  must  be  recognized  and  reckoned  with  at  run-time,  since 
the  positioning  of  the  partitioning  lines  is  governed  by  arbitrary 
expressions.   The  placement  of  these  lines  on  the  boundary  or  our- 
side  the  boundary  is  not  accidental;  it  is  a  result  of  conforming 
to  the  natural  demands  of  an  array  algorithm.   Consequently,  the 
definitions  and  conventions  which  we  adopt  are  chosen  to  be  con- 
sistent with  the  algebraic  structure  that  has  been  imbedded  into 
the  array  language.   These  considerations  suggest  that  we  define 
certain  operands  to  be  null.      The  terminology  is  chosen  because  it 
suggests  "emptiness"  which  is  a  characteristic  of  null  operands. 

In  order  to  define  null  operands  we  first  visualize  the  set- 
ting for  operands  which  are  not  null.   Every  array  has  a  set  of 
virtual  bounds  associated  with  it  as  defined  in  Table  1.   These 
bounds  define  the  (virtual)  boundaries  of  the  array  whether  the 
array  is  filled  with  elements  or  not,  and  whether  the  array  is 
one-dimensional  or  two-dimensional.   If  a  partition  line  lies 
inside  the  boundaries  of  an  array,  then  the  subarrays  which  are 
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DI-FINl  :  TON    OF    SYMBOLS 


*M: 

Null  Matrix 

V 

Null  Vector 

V 

Null  Scalar 

ADDITION  AND  SUBTRACTION 

*M 

±  M  =  M  ±  <1>M  =  M 

■i' 

V 

iV^Vi^^V 

s 

4-  s  =  S.'i  $   =  S 

s 

UNARY  OPERATIONS 

H:  Non-null  Matrix 
v:  Non-null  Vector 
s :       Non-null    Scalar 


VM  ~   M 

"  *M 

v     v 

=  *v 

$   i  $ 

s     s 

=  $ 

s 

V 

V 

±»s  =  4>s 

±$M   =    *M 
MULTIPLICATION   BY    SCALAR 

t  a  .  di  X      c;      =      S      X '    <f>  =      $ 

*M     ><     S     =     S     x     *        =     $M     ,  *y  *  -S  v 


x     S     =     S 


x 


Vs  =  *M  ;  Vs  =  * 


DIVISION* 

m/$s  =  4>M  ;  v/$s  =  $ 

Mill  /IMPLICATION 

*M    *    M   =■  M   x    $M   -    -M 


s 

*s 

V 

*s/s 

s 

V 

;  s/*s 

"  *s  ; 

% 

M 

fl)M 

$ 

y     4>    = 

$ 

(s    t    0) 


TRANSPOSE 

■i 


V    =    *M    ;    V 


FUNCTIONALS 

ll»M||  -  *s  ;  1 1 VI I  "  V  ;      (*"'v)      (V'*u)  = 


Fio   3  4  1   Operations  with  null  operands  arc  defined  for  matrices, 
™?;„r;   and  scalars.   These  definitions  apply  for  any  geometric  typ 


vectors,  and  sc; 

and  for  either  row  or  column  vectors 


'Division  by  $.  is  not  allowed  in  version  3  of  the  OL/2  compiler 


formed  by  splitting  the  array  along  the  partitioning  line  are 
mil    defined  subarrays,  and  they  have  the  property  that  they 
Iways  contain  at  least  one  element,  since  they  are  not  null. 


This  description  agrees  with  ou 


r  usual  method  of  partitioning 


.n  array  with  changes  to  accomodate  th 


e  geometric  types.   It  is 


easily  extended  to  two  or  more  (non-coincident)  partitioning 
lines.   The  essential  criterion  is  that  each  subarray  be  nonempty 

if  two  partitioning  lines  coincide,  or  if  a  partitioning 
line  falls  on  the  boundary  of  an  array,  then  a  null    operand    is 
created  and  rules  for  operating  with  these  operands  are  defined. 
From  tins  viewpoint,  a  null  operand  is  really  a  degenerate  sub- 
array  which  contains  no  elements.   For  instance,  the  subarrays 
R  and  M  in  Figure  3.3.5  are  degenerate  subarrays  when  K=l  ,  and 
are  defined,  therefore,  to  be  null  operands.   Similarly,  when  K>N 
the  subarrays  M  and  C  are  null.   At  all  other  times  R,  I),  M,  and 
;  C  are  defined,  and  the  array  expressions  (Figure  3.3.4)  which 
reference  these  subarrays  can  be  evaluated  unambiguously.   m 
particular,  when  K=l  and  R  and  M  are  null,  the  first  array  expres- 
sion is  evaluated  as  D=SQRTCD),  and  the  second  is  evaluated  as 
\CHQ/IK       When  K-N-,  the  second  expression  is  ignored. 

The  rules  which  govern  the  evaluation  of  array  expressions 
[which  contain  „„ll  operands  is  simple.   The  „„] 1    operand  behaves 

like  an  additive  Ldentity-a  zero  matrix,  a  zero  vector,  or  a 
■:ero  scalar.   The  main  difference  is  that  evaluations  .nvolving 
null  operands  require  no  compulation  or  additional  storage.   Dur- 
ing array  expression  evaluation,  temporary  null  operands  are  cre- 
ated where  necessary  and  are  combined  "behind  the  scenes"  aceordinc 
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:o  the  usual  algebraic  rules.   One  of  the  pleasant  consequences 
rf  null  operands  is  that  they  combine  with  other  operands  in 
;uch  a  way  that  the  initial  and  final  steps  of  an  algorithm  often 
require  no  special  statements. 

We  have  only  discussed  one  case  in  which  null  operands  are 
created;  namely,  when  two  partition  lines  are  superimposed;  the 
other  cases  are  simple  extensions.   If  a  partitioning  line  lies 
inside  the  boundaries  of  an  array  and  is  moved  toward  the  boundary, 
then  the  subarrays  which  are  defined  between  the  boundary  and  par- 
titioning line  become  null  when  the  line  meets  the  boundary.   If 
the  line  does  not  "cut"  the  array,  then  the  subarrays  which  would 
normally  be  defined  by  that  line  and  which  are  entirely  outside 
of  the  array  are  null,  but  those  that  contain  part  of  the  array 
are  not  nul 1 . 

The  above  description  is  not  intended  to  be  a  precise  defini- 
tion, but  rather  an  indication  of  how  null  operands  can  arise  and 
how  they  enter  into  the  evaluation  of  array  expressions.   In  Fig- 
ure 3.4.1  we  define  how  null  operands  are  to  be  treated  during 
array  expression  evaluation.   As  an  example,  we  consider  the  step 
by  step  evaluation  of  the  second  array  expression  in  Figure  3.3.4, 
under  the  assumption  that  M=$M  and  C=$V)  which  occurs  when  k=N,   No 
computation  is  required  in  this  evaluation. 

C  ..=  .(C  -  MxR'VD  -  (c  -  $MxR')/n 

C  =  (C  -  $y)/D  =  ($v  -  $v)/D 
C  =  $v/D  =  $y 
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EXAMPLE:   MAIN  PROCEDURE; 

N  =  5-, 

LET      A      BE   A  MATRIX    OF  ORDER    (N);      SET      L      TO   THE 
LOWER  TRIANGULAR  PART    OF  A;      A   =.0; 

FOR      K   =    N,    N-1,...,2;      PARTITION    L  AFTER    ROWS    K-1,    K; 
SET      R=L<2,1>; 


R   =    N    -   K   +    1  ; 
OUTPUT  A,    L; 


END; 
END   EXAMPLE; 
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3  .  5   Diagonal  Partitioning 

For  many  applications  it  is  necessary  to  reference  a  non- 
rectangular  part  of  an  array.   For  instance,  if  A  is  a  matrix  of 

rder  n,  it  is  quite  common  to  transform  A,  via  some  array  algor- 
ithm, into  a  simpler  form  such  as  lower  triangular  matrix  L,  while 

tilizing  the  storage  allocated  for  A.   In  order  to  provide  for  this 
introduce  the  "PART  OF"  construct,  which  is  used  within  a  SET 
statement.   For  example,  we  can  write:   "SET  L  TO  THE  LOWER  TRI- 
ANGULAR PART  OF  A."   The  effect  is  to  diagonally  partition  A  above 
the  main  diagonal,  assuming,  of  course,  that  A  is  square  (or 
rectangular) . 

Once  L  is  defined,  it  may  be  referenced  and  partitioned  inde- 
pendently of  A.   Figure  3.5.1  illustrates  this  feature  with  a 
lower  triangular  array.   Other  examples  can  be  constructed  which 
use  the  upper  triangular,  tridiagonal ,  or  diagonal  part  of  an 
array.   The  implementation  and  restrictions  arc  described  in  a 
sequel  to  this  report  [8,  9]. 

3.6   Nested  Partitioning 


In  the  previous  sections  wc  have  defined  static  and  dynamic 
partitioning;  furthermore,  we  have  defined  three  modes  of  parti- 
tioning—one for  triangular  and  diagonal  arrays,  another  for  rec- 
tangular (or  square)  arrays,  and  a  third  called  diagonal  parti- 
tioning.  Now  we  extend  the  partitioning  operation  to  subarrays. 
That  is,  once  a  subarray  is  defined  either  implicitly  by  the  place 
ment  of  partitioning  lines  or  explicitly  by  a  SET  statement -- that 
•subarray  is  itself  a  candidate  for  partitioning.   We  refer  to  this 
process  as  nested   partitioning.        \n    general,  partitioning  may  be 
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EXA1IPLE:      IIAIN   PROCEDURE; 

J    =    5;      N    =    Jx(J+1 )/2; 

LET      A      BE    A   I1ATRIX    OF  ORDER    (I!);      A=0; 
pnT?    K-i     2  J-       PARTITION      A     AFTER   ROVJS    K*(K-1)/2, 

KxCK^/^And'aFTER    COLUMNS    N-Kx(K+1)72,    N-K*CK-1  )/2  ; 


;i=A<2,2>;      PARTITION   II  AFTER   ROW    1;      SET   Q  =  H<7 
RO\!   VECTOR; 


SET 


END; 

END   EXAiiPLE; 


II   ='  K   +"    20; 
Q    =    -K-i 

OUTPUT   A; 


,A    *************  ■  ' 

"V    _2-    -3-    -4-    -5-    -6-    -7-    -b-    -9-10—  11-12-13-14-15- 

-1-        0        0        0        0        0        0        0        o        0        o        c        o        o        o      -i 

-2-000000000000-2-20 

J-  |j         o         u         n         n  n  n         °         °         °         °         ° 


oooooooo 


0  0  0  0  0  0  0  0  -3  -3  -3  0  0  0 

4  2  0  0  0  0  0  0  0  0  23  23  23  0  0  0 

I    I  0  0  0  0  0  0  0  23  23  23  0  0 

7  n  o  0  0  0  -4  -4  -4  -4  0  0  0  0  0  0 

llZ  0  0  0  0  0  24  24  24  24  0  0  0  0  0  0 

-9-  0  0  0  0  0  24  24  24  24  0  0  0  0  0  8 

1U-  0  0  0  0  0  24  24  24  24  0  0  0  0  0  0 

i-  1  -R  -S  -5  -5  0  0  0  0  0  0  0  0  0  0 


■!!_   -5   -5   -5   -5   -5 

12-   25   25   25   25   25    0    0 


13-   25   25   25   25   25    0    0 


oooooooo 
oooooooo 


14-       25       25       25       25       25         0 


oooooooou 


15-      25 


25       25       25       25         0         0         0  0 


oooooo 


Fig.  3.6,1   Example  of  nested  partitioning 
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applied  to  all  subarrays  which  result  from  previous 

and  the  process  may  be  continued  to  an  arbitrary  level.   Fi*ur 

3.6.1  illustrates  several  levels  of  partitioning 

In   practice,  two  or  three  levels  of  nested 
usually  sufficient  for  most  algorithms. 


partitioning  are 
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CHAPTER  4 
PROGRAM  STRUCTURE 

This  chapter  is  concerned  with  a  brief  description  of  those 
entities  in  the  OL/2  language  that  permit  one  to  identify  the 
structure  of  a  program.   For  the  most  part,  these  entities  con- 
sist of  conditional  forms,    repetitive  forms,    procedure  blocks, 
and  LET  blocks.   In  the  subsequent  sections  we  will  use  the  word 
"form"   to  denote  a  structural  entity;  the  meaning  will  become 
apparent  from  the  context  in  which  it  is  used. 

The  process  of  choosing  the  correct  entities  to  build  a 
well-structured  program  that  can  be  verified  depends  upon  the 
clairvoyance  and  discipline  of  the  programmer.   For  this  rea- 
son, we  recommend  to  those  who  have  not  already  become  acquainted 
with  it--Dijkstra*s  "Notes  on  structured  programming,"  [  2  ]  or 
the  more  recent  reference  [3].   In  the  next  section  we  sketch 
a  few  of  the  ideas  of  structured  programming  that  are  pertinent 
to  our  needs. 

4,1   Structured  Programming 

One  of  the  objectives  of  structured  programming  is  to  cre- 
ate programs  than  can  be  verified.   The  model  proposed  by 
Dijkstra  consists  of  an  arrangement  of  the  program  into  various 
levels,  where  each  level  corresponds  to  an  abstraction  of  the 
program  that  is  expressed  in  its  "own"  language  and  is  executed 
by  its  own  virtual  machine.   The  assumption  is  that  the  program 
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NORMAL  SEQUENCING  FORM: 


1 

1 

1 

t                                 i 

F  i      i 

i      ^U      ; 

!      &i     i 

i         LfJ        i 

i 

J 

s  i ;  s  2  ; . 

•  •  \ s  n  ' 

CONDITIONAL  FORMS 


r 


~i 


HEN  s 


IF  3  T 


REPETITIVE  FORMS 


L  _ 


si 


% 


—  — .     — 

< 

' 

3 

M 

s 

■— ■"■ 

IF  3  THEN   s2    ELSE    s2  CASE    i    OF    si;s2 


1 


WHILE  3  DO  s 


REPEAT  s  UNTIL  3 


FIG.  4.1.1   Flow  c 
that  are  used  by  D 


hart  symbols  and  corresponding  statement  forms 
ijkstra  to  control  the  sequencing  ot  a  program, 
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at  the  highest  level,  being  the  simplest  representation,  can  be 
verified  independently  of  lower  levels.   By  making  judicious 
decisions  one  refines  the  components  of  the  program  at  level  i 
to  obtain  a  program  at  level  i+l  which,  in  turn,  must  be  veri- 
fied.  Eventually,  one  reaches  a  level  at  which  the  program  can 
be  expressed  in  terms  of  a  language  that  can  be  executed  on  a 
machine . 

It  is  important  in  the  above  process  to  limit  the  types  of 
control  statements  which  determine  the  sequencing  of  a  program. 
The  restrictions  are  as  follows:   if  we  decompose  a  component 
of  a  program  into  smaller  parts  at  level  i,  say,  then  we  must 
connect  these  parts  together  by  choosing  one  (or  more)  of  the 
form,    in  Figure  4.1.1.   These  forms   do  not  constitute  an  abso- 
lute set,  but  rather  are  representative  of  the  forms   that  are 
allowed.   In  particular,  we  observe  that  each  of  these  forms 
has  the  property  that  there  is  only  one  input  and  one  output 
to  the  dotted  box.   Therefore,  loosely  speaking,  one  may  sub- 
stitute any  dotted  box  for  any  box  containing  an  s--since  it 
also  has  only  one  input  and  ono  output.   In  this  way  the  pro- 
gram structure  is  built  up  in  an  orderly  manner. 

In  the  next  sections  we  will  define  the  conditional  and 
repetitive  forms    in  OL/2.   Some  of  these  forms   differ  slightly 

from  those  in  Fieurp  4  I  l   k,,<-  +u~ 

ngure  4.1.1,  but  the  properties  required  for 

structured  programming  are  preserved. 
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CONDITIONAL    FORMS: 
(a)  , 


"1 


Zf 1 


(b) 


r 


IF  3  THEN  s1    FLSE  s2 


NESTING  OF  CONDITIONAL  FORMS  (resolving  the  ambiguous  case) : 


i  r 

3l 

THEN 

IF    32 

THEN 

sl 

ELSE 

s2 

1 


(<!) 


t 


IF  3i, 

THEN  IF  32 

THEN  s- 
ELSE  $ 
ELSE  s? 


1 


&L 

^ 

r 

"1 

32 

i 
1 
1 

L 

i 
i 

i 

sl 

cfc 

1 
1 

1 

| 

1 

I 


FIG.  4.2.1   Conditional  forms    In  OL/2.   The  ambiguous  construct 
"IF  3n  THEN  IF  3?  THEN  s-,  ELSE  s2'v  is  uniquely  defined  m  (cj  . 
The  symbol  <h    denotes  the  empty  statement  and  is  necessary  in  iaj . 
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4- 2   Conditional  Forms 

The  IF  statement  has  been  used  in  previous  chapters  in  the 
following  way: 

IF  {bool-expr}       THEN  {statement}; 
and 

IF  {bool-expr}      THEN  {statement}      ELSE  {statement}; 
where  {bool-expr}    denotes  a  Boolean  expression  whose  value  is 
true  or  false.   These  forms    are  displayed  in  Figure  4.2.1,  along 
with  the  nested  form    that  defines  how  the  ambiguou: 


is  case 


IF  6X  THEN  IF  32  THEN  3l    ELSE 


s 


is  to  be  resolved.   The  diagrams  of  the  conditional  forms    in 
Figure  4.2.1  are  clearly  consistent  with  the  principles  of  struc- 
tural programming.   In  particular,  after  the  .  part  is  executed 
then  the  sequencing  must  follow  the  path  indicated  in  the  diagram 

The  inclusion  of  arrays  allows  one  to  define  "array  compar- 
isons'".  For  instance,  one  can  write: 

IF  A<B  THEN  . .  .  ; 

where  A  and  B  are  (conformable)  arrays.   The  definition  of  A<B 
was  given  in  Figure  1.7.1  as  being  true  if  a..^  for  all  i,J 
and  false  otherwise.   A  similar  definition  applies  if  A  and  B 
are  one-dimensional  arrays. 

Occasionally  one  needs  to  write  an  array  comparison  which 
uses  the  "for  some"  qualifier,  for  instance,  "If  a..^..  for 
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CONDITIONAL:   MAIN  PROCEDURE*. 

LET  F,  G,  AND  II  BE  SCALARS  i 

F  =  4.1;  g  =  .01 ;  1I_=_2;_ 

r   --------  -  - 

l  •=  IF  F  <  3.14 

;      THEN   OUTPUT  Fi 

!      ELSE   OUTPUT  G; 


I  IF  F  >  3 .  1 4 

'  THEN   IF  G  <  .5 

1  THEN  OUTPUT  It; 

1  ELSE  OUTPUT  G; 


i   IF  F  <  3.14 

f      THEN   IF  G  <  .5 

1  THEN  OUTPUT  II ; 

I  else       ; 

,    else  output  fj 

;nd  conditional; 


-1 


I  G  x     x    x    I 
1 .000000E-02 

Hi   X      X      X     | 

2.000000E+00 

|  F  *    x    x   I 
4.10000QE+00 


FIG,  4.2.2   Several  examples  of  conditional  forms  corresponding 
to  Figure  4.2.1. 


ARRAY  COMPARISON 


70 


If  (aij<bij  for  all  i, j } 
then  si  else  s2 

If  (aij<b-[j  for  some  i,j} 
then  s±    else  s2 

If  aij<s  for  all  i,j 
then  ej  else  s2 

If  aij<s  for  some  i,j 
then  si  else  s2 

If  sefa-jj} 

then  si  else  s2 

If  s^{aij} 

then  si  else  s2 


OL/2  STATEMENT 


IF  A<B  THEN  9±    ELSE  s2 
IF  A>B  THEN  s2  ELSE  Sj 


IF  A<s  THEN  si  ELSE  s2 


IF  A>s  THEN  s2  ELSE  Sl 
IF  s  IN  A  THEN  s1    ELSE 


IF  s  IN  A  THEN  s2  ELSE  si 


array  comparisons.   Note  that 


PIG.  4.2.3  The  representation  of 

<?i  a-nA    ~  l-  i   ^  ^^cjiLdLiuji  or  onttv  Lumparisons.   Note  that 

in  tne  ?gFNW^5hpf«  Srb0lS  f0r  *"»>■    arePinterchanged 

the  S?oJ"sLe"  nh«L   s?e?iWhe?  the  "ray  comParis°^  ""tain 

(<■  =  ,>   1    keii  <=  h    fr  /0™S  apply  for  the  operators 
_>  ._>'/•   ine  symbol  s  denotes  a  scalar. 
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COMPARE:   MAIN  PROCEDURE; 

LET   A  AND  B   BE  TRIDI AGONAL  MATRICES  OF  ORDER (4) 5 

INPUT   A,  b; 
OUTPUT  A,  b; 

/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/ 

/x    IS  A(I,J)  <  B(I,J)  FOR  ALL  I, J  * / 

/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/ 

IF  A  <  B 

then  do;  b  =  B/2;  output  a,  b;  end; 

ELSE   A  =  A  +  B; 

/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/ 

/x    IS  A  (I,  J)  <  B(T,J)  FOR  SOME  I, J  */ 

/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/ 

IF  A  >=  B 

THEN   A  =  A  +  B; 

ELSE   DO;  B  =  B/2;  OUTPUT  A,  Bi  END; 

end  compare; 


A 


B 


1- 

2- 

3- 

•4- 


•1- 

■2- 

•3- 

■  4- 


-1- 

1  .00 
3.00 


A 


-1- 

1  .00 
3.00 


A 


-1- 

-2- 
-3- 
-4- 

FIG. 
some1 
array 
about 


•1- 

00 
,00 


-2- 

2.00 
4.00 
6.00 


-2- 
2.00 
4.00 
6.00 


5.00 

7.00       8.00 

9.00    10.00 


-3- 

5.00 
7.00 
9.00 


-4- 


8.00 
10.00 


-2- 
2.00 
4.00 
6.00 


5.00 
7.00 
9.00 


8.00 
10.00 


-1-  1 1 .00 
-2-  13.00 
-3- 

-4- 

12.00 
14.00 
16.00 

15.00 
17.00 
19.00 

18.00 
20.00 

|  B  x 

X       X 

X 

I 

-1-   5.50 
-2-   6.50 

-3- 

-4- 

6.00 
7.00 
8.00 

7.50 
8.50 
9.50 

9.00 
10.00 

|B  x 
-1- 

X       X 

-2- 

X 

-3- 

X        | 

-4- 

-1-   2.75 
-2-   3.25 
-3- 
-4- 

3.00 
3.50 
4.00 

3.75 
4.25 
4.75 

4.50 
5.00 

^trating  t 

:he  "fc 

.r  all" 

and  "fo 

4.2.4         An     a.  L  l  a.  y      ^umyuix^vii      ^.^.^ o  _ 

comparisons.   Note  that  the  language  does  not  specify  how  the 
comparison  is  implemented  and  therefore  nothing  can  be  concludec 
"efficiency"--which  is  necessarily  a  function  of  the  compiler 


and  the  underlying  computer  when  the  operations  are  primitive 
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;ome  i,j  then  .±   else  a 2"  where  Sj  and  .   represent  statements. 


This  may  be  accomplished  in  the  obvi 


ous  manner  by  writing 


IF  A>B  THEN  s2    ELSE  ^ 

/here  the  order  of  the  statements  in  the  THEN  and  ELSE  clauses 
are  interchanged. 

Arrays  may  also  be  compared  with  scalars.   We  say  that  A<s 
if  and  only  if  a. . <s    for  all  i,j.   Finally,  one  can  determine 
whether  or  not  a  scalar  s  is  an  element  of  an  array  A  by  using 
the  "IN"  operator.   Figure  4.2.3  shows  how  the  "for  some"  and 
"for  all"  are  represented  by  OL/2  statements. 

In  the  previous  examples  Sj    and  ^  represented  single  state- 
ments (or  forms)    in  the  THEN  and  ELSE  clauses  of  the  IF  statement 
If  more  than  one  statement  (or  form)    must  be  executed,  then  they 
must  be  delimited  by  a  "DO"  and  "END".   Thus,  Sl    (or  s 2)    in  the 
previous  examples  may  be  replaced  by  a  "normal  sequencing"  form 
such  as  , 

DO; 

sll 
s12 
S13 

END; 

where  fllj  are  themselves  (executable)  forms.      By  definition,  each 
form   8^0=1,2,3)  must  be  executed  in  sequent 


:e  . 


4.3   Repetitive  Forms 

For  FOR  statement  has  been  used  many  times  in  previous  chap 
ters,  of  which  the  following  are  examples: 
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REPETITIVE  FORMS 

FOR  a 

s 
END 


a 


FOR  a  OR  UNTIL  3 

s 
END 


WHILE  3 

s 
END 


L 


„ 

—    — 

' 

' 

3 

s 

— 

* 

' 

FIG   4.3.1   Repetitive  forms  in   OL/2.   In  these  .forms  s   may 
influence  (modify)  the  value  of  3  but  not  a.   The  second  form 
can  clearly  be  constructed  from  the  first  and  third. 
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I  FOR  K=1,2.,,,.N; 

FOR  K=1,2,...,N  OR  UNTIL  ||x-y||<eps; 
WHILE  |  jx-yj  |>eps; 
It  is  clear  that  this  syntax  is  closer  to  mathematical  notation 
|   than  the  corresponding  syntax  that  is  used  in  ALGOL  and  PL/I. 
|   Perhaps  more  important  is  the  fact  that  an  array  language  does 
not  reference  subscripted  variables  very  often,  and  therefore, 
the  number  of  repetitive  statements  that  are  used  is  consider- 
ably smaller  than  with  other  procedure  oriented  languages. 

In  general,  we  may  use  arbitrary  integer  (or  real)  expres- 
sions i1?  i2,  and  i3  to  control  the  repetitive  execution  of  a 
group  of  forms    s^    «2,  ...  sn   using  a  form    that  contains  as  its 
first  constituent  the  FOR  statement 

|  FOR  K-ilti2,...,i3; 

where  the  value  of  ^-^  is  the  positive  (or  negative)  increment 
that  is  algebraically  added  to  the  variable  K.   Thus,  except  for 
these  minor  syntatic  variations  the  FOR  statement  assumes  the 
usual  meaning. 

As  shown  in  Figure  4.3.1,  each  repetitive  form   is  composed 
;  of  three  constituents:   a  FOR  (or  WHILE)  statement,  one  or  more 

executable  forms   symbolized  by  s  and  an  END  statement.   The  repe- 
:  titive  forms   defined  in  Figure  4.3.1  preserve  the  properties  that 

are  needed  for  structured  programming,  as  is  evident  from  their 

corresponding  diagrams. 
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It  is  important,  however,  to  distinguish  between  the  two 
structurally  similar  forms    in  Figure  4.3.1;  namely, 

(i)   FOR  a;    s    END; 
(ii)   WHILE  3;  s    END; 

We  state  that  these  two  forms    differ  in  that  s  may  change  3 
in  (ii)  but  may  never  change  a    in  (i)  .   By  a,  of  course,  we  mean 
a  sequence  such  as  K=l,2,...n.   Therefore,  the  first  repetitive 
form    insures  that  only  a  finite  number  of  repetitions  will  be 
performed,  but  the  latter  form    does  not.   From  another  point  of 
view,  we  can  say  that  (i)  requires  a  priori  knowledge  about  the 
number  of  repetitions,  whereas  (ii)  merely  presupposes  the  exis- 
tence of  a  terminating  state  which  will  stop  the  repetition  at 
some  forseeable  moment  in  the  future.   It  is  apparent  that  the 
application  of  (i)  and  (ii)  in  general  will  be  different. 

4. 4   Procedures 

An  OL/2  procedure  may  be  one  of  the  following:   a  main  pro- 
cedure, an  internal  procedure,  or  an  external  procedure.   All 
of  the  examples  in  previous  chapters  were  written  as  main  pro- 
cedures . 

A  main  procedure  is  identified  by  a  "main  procedure  statement" 
and  a  corresponding  END  statement.  For  example,  if  an  algorithm, 
say  ALG_A,  is  to  be  constructed,  then  one  writes: 

ALG_A:   MAIN  PROCEDURE; 

END  ALG  A; 


LL_ 


76 
where  ALG_A  is  an  arbitrarily  chosen  label.   Every  program  con- 
sists of  one  and  only  one  main  procedure;  however,  a  program  may 
contain  other  procedures  in  addition  to  the  main  procedure.   If 
the  text  of  a  procedure  is  placed  inside  the  main  procedure  it 
is  called  an  internal   procedure  ,  otherwise,  an  external    proced- 
ure.     The  declaration  and  use  of  procedures  in  OL/2  is  chosen 
to  be  consistent  with  the  usual  conventions,  however,  the  passing 
of  array  parameters  is  extended  to  make  the  OL/2  array  language 
more  useful  and  to  allow  the  introduction  of  "invariant  proced- 
ures" into  the  language.   These  ideas  will  be  discussed  elsewhere, 

Internal  and  external  procedures  are  delimited  by  a  proced- 
ure statements  and  a  corresponding  END  statement,  and  they  may 
contain  an  optional  list  of  formal  parameters.   For  example, 
ALG_A1  below,  is  a  procedure  with  formal  parameters  A,  B,  and  C. 

ALG_A1:   PROCEDURE  (A,  B,  C) ; 
LET  A,B,C  BE  . . . ; 

END  ALG_A1; 
As  is  customary,  this  procedure  may  be  called  by  a  procedure 
"CALL"  statement  such  as, 

CALL  ALG_A1  (cx,3,y)  ; 

where  a,  3,  and  y   are  actual  parameters  that  correspond  respec- 
tively to  the  formal  parameters  A,  B,  and   C.   The  keyword 
CALL  may  be  replaced  with  a  synonym  without  altering  the  meaning 
or  structure  of  a  program.   The  substitution  of  a,  3,  and  y    for 
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LET  FORM 


X:   LET  v 
s 
END  X 


NESTED  LET  FORMS 

X]_.:  LET  vx 

sll 

LET  v7 


21 
22 


END 


S12 


X3:  LET  v3 

s31 

END  X3 


s13 
END  Xx 


VRo 


1 


r 


(v2) 


"1 


x  -1 


FIG.  4.5.1 
The  symbol 
outside  of 


Conventional  structure  associated  with  LET  blocks 
v  denotes  a  set  of  variables  which  are  not  known 
their  own  block.   The  symbol  X  denotes  a  label. 
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A,  B,  and  C  everywhere  in  the  procedure  declaration  defines  th 
:omputational  process.   As  indicated  earlier,  procedures  foil 
;he  usual  conventions  whenever  possible. 

In  terms  of  our  previous  conventions,  a  procedure  declar- 
tion  is  not  a  form   because  it  cannot  become  a  part  of  the  se- 
luencing  control  by  itself;  it  must  rely  upon  a  procedure  "CALL" 
itatement  to  connect  it  temporally  to  the  sequencing  control. 

•  5   Block  Structure 

There  are  two  types  of  blocks  in  OL/2:   LET  blocks  and 
procedure  blocks.   A  procedure  block  consists  of  an  entire 
procedure  declaration;  that  is,  a  PROCEDURE  statement,  a  cor- 
responding END  statement,  and  all  intervening  program  text.   In 
particular,  the  main  procedure  is  a  block,  and  so  is  each  in- 
ternal procedure  declaration. 

LET  blocks  are  forms   which  are  recognized  by  an  opening 
LET  statement  (or  a  sequence  of  LET  statements)  and  a  corres- 
ponding END  statement,  e.g., 

BL0CK_1:   LET  A,B,  AND  C  BE  ...; 


END  BL0CK_1; 

This  implies  that  the  placement  of  LET  statements  determines  the 
i  non-procedure  block  structure  of  a  program.   The  label  in  the 
above  example  is  not  necessary  unless  the  END  statement  serves  to 
close  more  than  one  block.   In  other  words,  if  every  LET  block 
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BLOCKS:   MAIN  PROCEDURE; 

u   =  3 ;  

LET   A  AND  B   BE  ARRAYS  OF  ORDER  (N) 


,  B1 


INPUT   A,  b; 

output  a,  b; 


v~l 


1  B2:   LET   A   BE  A  LOWER  TRIANGULAR  ARRAY  ^ 
!      I       OF  ORDER (N) J 


,         input  a,  b; 
■'         output  a,  b; 

1  END  B2; 

OUTPUT  A,  Bi 


END  B1 i 


I 

END  BLOCKS^ 


|A  x 
-1- 

1-  1 

2-  4 

3-  7 

X 

-2- 

2 
5 

8 

x    I 

-3- 

3 
6 

9 

|A  x 
-1- 

X 

-2- 

x    I 

-3- 

1-  19 

2-  20 
•3-    22 

21 
23 

24 

|A  x 

-1- 

-1-      1 

-2-     4 

-3-     7 

X 

-2- 
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8 

x   I 

-3- 
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6 

9 

|B  x 

X 

x    I 

-1- 

-2- 

-3- 

-1-    10 

11 

12 

-2-    13 

14 

15 

-3-    16 

17 
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|B  x 

X 
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-1- 

-2- 

-3- 

-1-    25 
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33 

|B  x 

X 

x    I 

-1- 

-2- 
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-3-    31 

32 
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FIG.  4.5.2   A  (main)  procedure  block  with  two  nested  LET  forms 
illustrating  conventional  scope  rules. 
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is  terminated  with  a  distinct  END  statement,  then  all  block 
labels  on  LET  blocks  may  be  removed. 

LET  blocks  serve  to  declare  local   variables.   If  a  vari- 
able is  a  local  variable,  then  it  is  not  defined  outside  of  its 
block;  however,  it  may  be  defined  and  used  in  another  block  that 
is  nested  within  the  current  block.   For  example,  the  array  B 
in  Figure  4.5.2  is  known  everywhere  in  block  Bl .   Within  block 
B2,  the  array  B  is  a  global    variable,  but  with  respect  to  block 
Bl  it  is  a  local  variable. 

Figure  4.5.2  also  illustrates  the  scope  of  the  arrays  A 
and  B.   Since  A  is  declared  in  both  block  Bl  and  block  B2  there 
are  two  distinct  generations  of  A;  the  second  A  which  is  declared 
in  B2  is  distinct  from  the  first  A  declared  in  Bl.   The  output  of 
A  shows  the  scope  associated  with  each  A.   These  are  the  familiar 
conventions  of  PL/I  and  ALGOL. 

We  summarize  the  block  conventions: 

(i)  Each  PROCEDURE  statement  opens  a  block  while 
a  matching  END  statement  (which  contains  the 
procedure  name)  closes  the  block. 

(ii)  Any  LET  statement  which  is  immediately  preceded 
by  an  executable  statement  opens  a  LET  block 
while  a  matching  END  statement  closes  the  block. 

In  particular,  a  LET  statement  which  immediately  follows  a 
procedure  statement  does  not  open  a  new  block.   Similarly,  a 
LET  statement  which  immediately  follows  another  LET  statement 
does  not  open  a  new  block.   For  instance,  in  Figure  4.5.1  we  may 
delete  the  statement  "N=3;»  and  replace  "ORDER(N)"  with  "0RDER(3)". 
Now  B2  is  the  only  block  inside  the  main  procedure  block,  and 
therefore  "END  Bl;"  must  be  deleted. 


4.6   Summary  of  Program  Structure 

An  OL/2  program  consists  of  a  main  procedure  block  followed 
>y  a  (possibly  empty)  list  of  external  procedure  blocks.   There 
ire  two  representations  of  main  procedure  blocks,  namely 


MAIN  PROCEDURE 
LET  v 


{Si) 


A :   MAIN  PROCEDURE 


{Si> 


END  A 


END  A 


where  {s.}  denotes  a  (possibly  empty)  sequence  of  forms .   An  ex- 
ample of  the  first  is  Figure  4.2.4  and  the  latter  Figure  4.5.2. 
It  should  be  clear  from  the  previous  sections  that  the  form    is 
the  basic  structural  unit  and  not  the  statement.   As  shown  in 
Figure  4.6.1,  some  statements  are  also  forms ,  but  not  all  of  them. 
The  symbol  a    is  used  to  denote  a  form.      Thus,  wherever  s    occurs 
in  Figure  4.6.1  any  form  (including  the  form  itself)  may  be  substi 
tuted;  wherever  {s.}   occurs  any  sequence  of  forms   may  be  substi- 

1  tuted. 
i 

The  form    is  merely  an  artifice  which  allows  us  to  see  the 

correspondence  between  the  program  structure  and  the  execution 
sequence  of  the  program.   In  particular,  a  sequence  of  forms  {s.} 
is  executed  in  the  order  in  which  they  are  written.   Since  proce- 
dure blocks  are  not  forms    they  cannot  alter  the  sequence  of  exe- 
cution; they  enter  into  the  sequence  only  by  "substitution"  or 
by  being  called. 
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FORMS   WHICH  CONTAIN  FORMS 


Classification 


FORMS 


Sequential 


DO 


{S.} 
1 


END 


Conditional 

IF  3        ; 

IF  3           ; 

THEN  s 

THEN  s 
ELSE  s 

Repetitive 

FOR  a 

is.} 

l 

FOR  a  OR  UNTIL  3 

is.) 

l 

WHILE  3 

is.} 

l 

END 

END 

;     END 

BLOCKS  WHICH  ARE  FORMS 


Let 


LET  v 


{Si} 


END 


STATEMENTS  WHICH  ARE  FORMS 


Null 

Assignment 

I/O 


V=  E 

INPUT   v 
OUTPUT  £ 


Partition  PARTITION.. . 

Set  SET... 

Interchange        INTERCHANGE . 


SUBSTITUTION  FORMS 

Mappings  p-*v 

Procedure  Calls     CALL  p 


FIG.  4.6.1   The  abstract  representation  of  forms 

For  convenience,  no  semi-colons 


The  Greek  letters 

symbolize  the  variable  text  part. 

are  used,  though  in  concrete  representations  they  must  be  Present 
The  symbol  s    denotes  a  form   and  {Si}    a  sequence  of  forms.      Mapping 
will  be  discussed  elsewhere. 
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Let  blocks  are  special  forms    that  allow  one  to  define  local 
variables  in  the  conventional  way. 

Figure  4.6.1  summarizes  the  representation  of  forms    that 
are  used  to  build  the  program  structure.   As  indicated  earlier, 
the  form    is  merely  an  artifice  that  allows  us  to  describe  the 
program  structure  in  a  fairly  straightforward  manner. 
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